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EXECUTIVE  SUMMARY 


The  Computer  Security  Act  of  1987  (Pub.  L.  100-235)  and  Office  of  Management 
and  Budget  Circular  A- 130  mandate  that  U.S.  Government  agencies  protect 
automated  information  and  the  resources  used  to  process  it  (hardware,  firmware,  and 
software).   OMB  Circular  A- 130  specifically  mandates  that,  as  a  part  of  protecting 
computer  systems,  agencies  incorporate  computer  security  in  the  system  acquisition 
process.   This  NIST  Special  Publication  provides  guidance  for  federal  procurement 
initiators,  contracting  officers,  and  computer  security  officials  on  including  computer 
security  in  acquisitions. 

To  accomplish  this  goal,  computer  security  and  federal  information  processing  (FIP) 
procurement  must  be  integrated.   Computer  security  is  the  protection  of  the  integrity, 
availability  and  confidentiality  of  automated  information  and  the  resources  used  to 
enter,  store,  process,  and  communicate  the  information.   Computer  security  shares 
properties  with  systems/software  engineering  including  trustworthiness,  system  safety, 
and  reliability.  FIP  procurement  is  the  process  of  acquiring  hardware,  software, 
firmware,  computer-related  services  and  telecommunications.  FIP  procurement 
begins  with  the  process  of  determining  needs  and  ends  with  contract  completion. 

The  integration  of  computer  security  and  FIP  procurement  will  result  in 
improvements  in: 

meeting  agency  missions; 
protecting  federal  assets;  and 
protecting  individual  rights. 

The  integration  is  accomplished  by  incorporating  computer  security  into  all  phases  of 
the  procurement  cycle:   planning,  solicitation,  source  selection,  and  contract 
administration  and  closeout. 

This  guideline  is  based  on  the  collective  experience  of  government  and  industry 
personnel  from  the  fields  of  computer  security,  procurement,  and  information 
resources  management  and  is  intended  to  be  used  in  conjunction  with  agency  or 
General  Services  Administration  guidance  on  procurement  and  computer  security. 
This  guideline  neither  addresses  nor  supersedes  requirements  for  the  protection  of 
national  security  information  resources. 

NIST  has  prepared  a  related  document  that  addresses  the  area  of  computer  security 
and  procurement,  Sample  Statements  of  Work  for  Federal  Computer  Security 
Services,  which  provides  assistance  to  agencies  that  are  contracting  for  computer 
security  services,  such  as  performing  a  risk  analysis. 
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PREFACE 


Computers  and  information  play  an  increasingly  important  role  in  modern  society. 
More  people  use  computers,  more  information  is  processed  and  stored  by  them,  and 
our  nation's  dependence  on  computers  continues  to  grow.   Therefore,  it  is  essential 
to  protect  computers  and  the  information  they  contain. 

From  a  practical  standpoint,  computer  viruses,  white-collar  crime,  theft  of  hardware 
and  software,  unauthorized  access  to  data,  and  damage  and  destruction  of  computer 
systems  by  people  or  nature  are  real  threats.  Computer  security  shows  its  worth  in 
preventing  loss  or  harm.  The  meaning  of  terms  like  "appropriate  and  cost-effective 
safeguards"  are  truly  appreciated  when  explaining  how  a  loss  was  or  was  not 
prevented. 

Due  to  the  vital  need  to  protect  computer  systems,  the  National  Institute  of 
Standards  and  Technology  (NIST)  provides  standards  and  guidelines  on  many 
aspects  of  computer  security.   This  document  addresses  the  specific  issue  of 
including  computer  security  requirements  in  federal  information  processing  (FIP) 
procurements.   A  NIST-sponsored  working  group  of  government  and  industry 
representatives  in  computer  security,  information  management,  and  FIP  procurement 
helped  to  develop  this  document. 
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CHAPTER  I 


INTRODUCTION 


A.  REQUIREMENT 

The  need  to  provide  protection  for  federal  automated  information  assets  has  been 
present  since  computers  were  first  used.  The  Office  of  Management  and  Budget 
(OMB)  formally  established  a  federal  computer  security  policy  in  1978  and  updated 
that  policy  in  OMB  Circular  A- 130,  dated  December  1985.   Congress  passed  several 
laws  relevant  to  computer  security,  including  the  Computer  Security  Act  of  1987. 
Both  Congress  and  OMB  update  and  revise  federal  policies  and  regulations  on 
computer  security.   Computer  security  concepts  and  practices  are  discussed  in 
section  ILA,  Computer  Security. 

In  order  to  meet  these  policies  and  regulations,  federal  agencies  must  include 
computer  security  considerations  in  all  phases  of  information  resources  management. 
OMB  Circular  A- 130  and  the  Federal  Information  Resources  Management  Regulation 
(FIRMR)  require  security  specifications  for  systems  acquisitions.  In  general, 
including  computer  security  in  the  acquisition  phase  results  in  less  expensive  and 
better  security  than  adding  security  to  an  operational  system.  This  document 
provides  guidance  on  including  computer  security  considerations  in  the  acquisition 
phase  of  information  resources  management. 

B.  SCOPE 

This  document  is  intended  to  help  agencies  select  and  acquire  cost-effective 
computer  security  by  explaining  how  to  include  computer  security  requirements  in 
federal  information  processing  (FIP)  procurements.  The  guideline  has  three  parts. 
The  first  part  is  an  introduction  to  the  two  disciplines: 

computer  security  (targeted  for  FIP  procurement  personnel);  and 
FIP  procurement  (targeted  for  computer  security  personnel). 

These  overviews  provide  sufficient  knowledge  to  understand  the  legal,  conceptual, 
and  regulatory  underpinnings  of  the  document.  It  should  not  be  used  as  a  sole 
guide  to  computer  security  or  FIP  procurement. 
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The  second  part  explains  the  integration  of  computer  security  into  the  FIP 
procurement  process.  The  guideline  recommends  that  the  following  analyses  be 
included  in  procurement  documentation: 

sensitivity  determination; 

analysis  of  integrity,  availability,  and  confidentiality  requirements; 
analysis  of  level  of  assurance  required;  and 
planning  phase  risk  analysis. 

The  guideline  also  provides  assistance  on  the  selection  of  computer  security  features, 
assurances,  and  procedures.  The  guideline  clarifies: 

what  sources  of  features,  assurances,  and  procedures  are  required  to  be  used 
by  law  or  regulation;  and 

what  other  sources  are  available  and  how  to  use  them. 

The  third  part  of  the  document  includes  specifications  and  contract  language  for 
specific  computer  security  features,  assurances,  and  procedures  that  can  be  included 
in  FIP  procurements. 

This  document  does  not  address  the  procurement  of  computer  security-related 
services,  such  as  the  development  of  risk  analyses  and  contingency  plans.  NIST  has 
prepared  a  separate  document,  Special  Publication  800-4,  Sample  Statements  of  Work 
for  Federal  Computer  Security  Services,  to  address  procurement  of  these  services. 

This  document  is  not  a  substitute  for  agency  procurement  or  security  regulations, 
policy,  and  guidance.  It  is  intended  to  be  used  in  conjunction  with  these  agency 
regulations.  This  document  does  not  address  computer  security  requirements  for 
national  security  or  Warner  Amendment  information  resources. 

C.  TARGET  AUDIENCE 

This  document  targets  procurement  initiators  (the  sponsor,  program  manager,  or 
person  who  will  become  the  contracting  officer's  technical  representative), 
contracting  officers,  and  computer  security  officials. 

D.  TERMINOLOGY 

The  terms  computer,  computer  system,  automatic  data  processing  (ADP),  automatic 
data  processing  equipment  (ADPE),  federal  information  processing  (FIP)  resource, 
information  technology  support  (ITS),  information  resources  (IR),  and  automated 
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information  system  (AIS)  are  used  interchangeably  throughout  the  government.  In 
this  document,  the  term  FIP  procurement  is  used  because  it  is  the  term  used  in  the 
FIRMR,  and  the  term  computer  security  is  used  because  it  is  the  most  common. 
Both  FIP  procurement  and  computer  security  address  the  resources  and  services  used 
to  enter,  store,  process,  and  transmit  automated  information  and  data. 

Appendix  D  contains  a  glossary  of  selected  computer  security  and  procurement 
terms. 
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CHAPTER  II 


BACKGROUND 


This  chapter  provides  a  general  introduction  to  computer  security  and  FIP 
procurement.   The  section  on  computer  security  is  targeted  for  contracting  officers. 
The  section  on  FIP  procurement  is  targeted  for  computer  security  officials.  The 
sections  are  not  complete  step-by-step  procedures,  but  provide  background  for  the 
rest  of  the  guideline. 

A.   COMPUTER  SECURITY 

Computer  security  is  the  protection  of  the  integrity,  availability  and,  if  needed, 
confidentiality  of  automated  information  and  the  resources  used  to  enter,  store, 
process,  and  communicate  it.  Computer  security  is  often  referred  to  in  conjunction 
with  system  trustworthiness,  integrity,  safety,  availability,  and  reliability.   In  the 
federal  government,  the  primary  policy  mandates  for  protecting  computer  assets  are 
in  OMB  Circular  A- 130,  "Management  of  Federal  Information  Resources," 
specifically  Appendix  III,  "Security  of  Federal  Automated  Information  Systems,"  and 
the  Computer  Security  Act  of  1987. 

This  section  addresses  basic  computer  security  concepts  and  practices,  based  on 
OMB  Circular  A- 130  and  the  Computer  Security  Act.  Understanding  these  concepts 
and  practices  helps  procurement  initiators  and  contracting  officers  properly  integrate 
computer  security  considerations  into  procurements. 

A.l.   BASIC  COMPUTER  SECURITY  CONCEPTS 

Several  basic  concepts  in  computer  security  are  described  below: 

Management  Issue.   Computer  security  is  an  increasingly  important  issue  for  all 
federal  managers.  Modern  technology  allows  federal  agencies  to  store  and  process 
vast  amounts  of  data  in  support  of  agency  functions.  Federal  computer  and 
information  assets  have  great  value  and  need  to  be  managed  to  the  same  extent  as 
the  more  traditional  organizational  assets  (i.e.,  employees,  money,  equipment,  natural 
resources,  and  time). 

Value  of  Information  and  Computing  Resources.  The  value  of  federal 
information  and  computing  resources  and  the  importance  of  federal  agency  missions 
create  a  need  for  these  resources  to  be  adequately  protected.  Owners  and  users  of 
the  information  provide  the  impetus  for  protecting  these  valuable  resources. 
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Functional  Requirement.   Computer  security  is  a  functional  requirement  of  most 
systems.   If  data  is  not  accurate,  complete,  timely,  available,  and,  if  necessary, 
confidential,  then  the  system  may  be  unable  to  perform  its  basic  function. 

Individual  Privacy.   Automated  information  about  individuals  must  be  protected  in 
accordance  with  the  Privacy  Act  of  1974  and  other  statutes. 

Life  Cycle  Phases.  Many  systems  are  designed,  developed,  and  implemented  over 
months  or  years.   A  system  life  cycle  is  used  to  manage  a  system  from  its  inception 
through  its  development,  implementation,  and  operation  until  its  termination.  If 
security  is  initially  designed  into  a  computer  system,  the  safeguard  options  are  vastly 
increased  and  the  security  costs  over  the  life  of  the  system  are  substantially  reduced. 
Since  the  system  environment  and  technology  may  change  during  the  system  life 
cycle,  the  security  will  need  to  change  also.   Therefore,  it  is  important  for  all 
managers  to  ensure  that  security  is  appropriately  addressed  in  all  phases  of  the  life 
cycle  for  computer  systems,  especially  in  the  early  planning  stages. 

Some  automated  systems  are  acquired  "off-the-shelf"  and  can  be  used  immediately. 
In  procuring  these  systems,  initiators  must  consider  the  systems'  present  security 
features  and  expandability  to  meet  future  security  needs.   Many  vendors  offer 
security  features  on  off-the-shelf  systems  which  may  be  ordered  separately  and 
installed  after  the  system  is  in  operation. 

Computer  Security  Incidents.   In  recent  years  federal  agencies  have  become  aware 
of  more  computer  security  incidents.  These  incidents  result  from  intentional  and 
unintentional  actions  by  internal  (government  and  contractor)  personnel  and  outsiders. 
These  incidents  result  in  monetary  losses  and  decrease  an  agency's  productivity  and 
even  its  ability  to  perform  its  mission.  While  advances  in  computer  and 
telecommunications  technology  help  prevent  many  problems,  the  difficulty  of 
managing  the  rapid  change  and  the  technical  complexity  can  increase  the  federal 
government's  vulnerability  to  incidents. 

Balance.   Absolute  security  is  virtually  impossible.  Federal  agencies  cannot  totally 
protect  their  computer  systems  from  every  possible  threat  for  numerous  reasons, 
including  the  following: 

Absolute  protection  would  make  the  agency's  systems  virtually  inaccessible 
and  unusable; 

Some  vulnerabilities  may  not  be  known,  as  in  the  case  where  application  code 
contains  security  flaws;  and 
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Computer  security,  like  other  disciplines,  depends  on  people,  who  are  capable 
of  error  and  dishonesty. 

Goal.  The  goal  of  federal  computer  security  is  to  support  the  mission  of  the  agency 
by  providing  cost-effective  protection  that  assures  the  integrity,  availability,  and 
confidentiality  of  automated  information  and  the  resources  used  to  process  it. 

There  are  few  clear  rules  for  accomplishing  this  goal.  Nevertheless,  OMB  Circular 
A- 130  requires  that  the  following  types  of  protective  measures  be  used,  alone  or  in 
combination,  to  cost-effectively  provide  appropriate  protection: 

•  Technical; 

•  Personnel; 

•  Administrative; 

•  Environmental;  and 

•  Telecommunications. 

Figure  1  shows  how  protective  measures,  called  safeguards,  are  used  to  protect 
assets  from  threats.  These  safeguards  can  be  internal  or  external  to  the  system.  A 
threat  is  any  circumstance  or  event  with  the  potential  to  cause  harm  to  a  system  in 
the  form  of  destruction,  disclosure,  modification,  and/or  denial  of  service.  If  a 
safeguard  is  missing  or  inadequate,  a  threat  can  "get  through"  and  damage  assets. 
The  damage  to  the  asset  has  an  impact  on  the  agency.  The  "gap"  between  the 
safeguards  is  referred  to  as  a  vulnerability.  The  selection  of  safeguards  for  a 
specific  computing  environment  is  based  on  an  assessment  of  the  assets,  impacts, 
threats,  probabilities,  vulnerabilities  and  the  adequacy,  availability,  and  cost  of 
safeguards.  This  process  is  called  risk  analysis. 
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Figure  1.  Threats,  Safeguards,  Vulnerabilities,  &  Assets. 


Multidisciplinary  Coordination.   All  traditional  management  disciplines  and 
functions  must  be  employed  in  a  coordinated  fashion  to  effectively  manage  computer 
security.   Over  the  years,  federal  agencies  have  become  more  dependent  on 
automation  technologies  to  support  all  aspects  of  their  operations  and  missions.  As 
a  result,  there  are  many  security-related  disciplines,  each  with  its  own  set  of  policies 
and  procedures. 

Figure  2  shows  possible  functional  areas  in  an  agency  with  responsibilities  that 
overlap  with  computer  security.   Many  of  these  are  separate  career  fields  within  the 
government.   Only  when  all  disciplines  are  working  together,  in  a  highly  coordinated 
fashion,  can  the  entire  security  process  function  properly  and  efficiently.  Thus, 
computer  security  managers  at  all  levels  must  regularly  coordinate  with  personnel  in 
other  security-related  disciplines. 
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Figure  2.  Multidisciplinary  Coordination. 
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A.2.   BASIC  COMPUTER  SECURITY  PRACTICES 


In  practice,  certain  basic  actions  are  necessary  in  all  federal  computer  security 
programs.  These  include: 

Develop  Computer  Security  Policy/Procedures.  Computer  security  policies  and 
procedures  are  needed  to  define  the  overall  framework  for  implementing  and 
sustaining  an  efficient  and  cost-effective  computer  security  program  at  the  federal 
agency  level.  The  policy  establishes  lines  of  authority,  roles  and  responsibilities, 
and  basic  principles  and  requirements  which  define  the  computer  security  program. 
The  procedures  contain  implementation  and  compliance  instructions  and  management 
processes. 

Institute  Computer  Security  Planning.  Computer  security  planning  must  provide  a 
consistent  approach  for  determining  short-  and  long-range  management  objectives, 
developing  security  enhancement  proposals,  mapping  proposals  to  budget  requests, 
and  assuring  the  implementation  of  cost-effective  protective  measures. 

Institute  a  Sensitivity  Identification  Process.  The  Computer  Security  Act  requires 
that  agencies  identify  sensitive  systems.   In  order  to  accomplish  this,  agencies  must 
institute  a  process  for  determining  sensitivity. 

Define  and  Implement  a  Risk  Analysis  Program.  This  program  should  ensure  the 
performance  of  risk  analyses  on  agency  systems.  Federal  managers  need  to 
continually  identify  and  analyze  potential  threats  to  their  computing  and 
telecommunications  environments  and  take  action  to  reduce  risk  exposures  to 
acceptable  levels. 

Establish  a  Protective  Measure  Baseline.  There  are  numerous  combinations  of 
technical,  personnel,  administrative,  environmental,  and  telecommunications  protective 
measures  available  to  federal  managers.  While  OMB  Circular  A- 130  defines  a 
governmentwide  security  baseline,  an  organization-specific  security  baseline  can  help 
an  agency  ensure  adequate  protection  of  resources. 

Ensure  the  Conduct  of  Certifications  and/or  Accreditations.  Computer  security 
certifications  and/or  accreditations  are  a  management  control  for  ensuring  that 
installed  security  safeguards  are  adequate. 

Oversee  a  Multi-layer  Compliance  Assurance  Mechanism.  Management  and 
compliance  reviews  should  be  conducted  periodically  to  sustain  optimal  security 
levels. 
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Develop  an  Incident  Response  and  Reporting  Mechanism.  Agencies  should 
develop  appropriate  responses  to  security  incidents  and  provide  feedback  information 
to  senior  management  on  significant  incidents.  This  reporting  also  supports  the 
tracking  of  agencywide  trends. 

Ensure  Continuous  Awareness  and  Training.  Continuous  awareness  and  training 
are  necessary  to  elevate  and  sustain  management  and  personnel  awareness  and  to 
provide  specific  guidance  for  personnel  who  design,  implement,  use,  or  maintain 
computer  systems. 

Ensure  Contingency  Planning.  Contingency,  disaster  recovery,  and  continuity  of 
operations  plans  provide  continued  processing  capability  when  other  safeguards  have 
failed  to  maintain  system  reliability  or  availability.   Such  plans  should  be  in  place 
and  tested  periodically. 

Ensure  Personnel  Screening.  Personnel  who  participate  in  managing,  using, 
designing,  developing,  operating,  or  maintaining  computer  systems  should  be 
appropriately  screened.  The  level  of  screening  should  be  commensurate  with  the 
loss  or  harm  that  could  be  caused  by  these  individuals.   This  applies  to  both  federal 
and  contractor  personnel.  The  Office  of  Personnel  Management  defines  screening 
requirements  for  federal  personnel. 

Develop  Appropriate  Acquisition  Requirements.  In  contracts  for  hardware, 
software,  and  computer-related  services,  federal  agencies  must  ensure  that: 

appropriate  security  requirements  and  specifications  are  included  in  statements 
of  work;  and 

security  requirements  and  specifications  are  implemented  properly  before  the 
system  goes  into  operation. 

B.   FIP  PROCUREMENT 

This  section  provides  a  general  introduction  to  FIP  procurement  for  computer 
security  officials.  The  section  is  not  a  complete  "how  to"  but  provides  background 
for  the  rest  of  the  guideline. 

The  acquisition  of  federal  information  processing  (FIP)  resources  has  discrete 
characteristics  that  distinguish  it  from  the  acquisition  of  other  supplies  or  services. 
FIP  acquisitions  have  unique  authority,  approval,  and  documentation  requirements. 
These  requirements  flow  from  various  laws  and  are  implemented  in  two  primary 
regulations: 
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Federal  Acquisition  Regulation  (FAR);  and 

Federal  Information  Resources  Management  Regulation  (FIRMR). 

FIP  procurement,  as  defined  by  the  Brooks  Act,  the  Paperwork  Reduction 
Reauthorization  Act,  and  the  FIRMR,  involves  the  acquisition  of  computer  hardware, 
software,  firmware  and  related  services  including  telecommunications  and  support 
services. 

The  FIRMR  is  the  primary  regulation  for  use  by  federal  or  executive  agencies  in 
their  management,  acquisition,  and  use  of  information  processing  resources.   It  is 
issued  by  the  General  Services  Administration  (GSA),  which  has  primary 
responsibility  for  the  management  of  FIP  resources  in  the  federal  government. 

Note:   This  section,  like  the  rest  of  the  document,  does  not  address  national  security 
systems  or  systems  covered  by  the  Warner  Amendment.   (See  glossary  for  a 
definition  of  Warner  Amendment  systems.) 

The  following  sections  address  FIP  procurement  concepts  and  practices. 
B.l.   BASIC  PROCUREMENT  CONCEPTS 

It  is  essential  to  have  a  basic  understanding  of  the  underlying  goals  and  objectives 
of  the  government's  procurement  procedures.   Without  this  understanding,  the 
procurement  process  can  be  confusing  and  its  rules  can  appear  intractable  and 
obscure.   Under  these  conditions,  it  is  difficult  to  include  computer  security.  In 
addition,  because  conflicts  and  problems  sometimes  arise  during  a  procurement, 
knowledge  of  the  underlying  goals  and  objectives  will  help  the  procurement  initiator 
work  with  the  procurement  staff  to  resolve  problems. 

The  following  analysis  is  a  basic  tutorial  on  the  essential  elements  of  federal 
government  procurement.   It  is  not  intended  to  substitute  for  the  FAR,  the  FIRMR, 
or  your  agency's  procurement  guidelines. 

Federal  procurement  is  governed  by  its  underlying  goals.  These  goals  are: 

to  obtain  quality  products  that  meet  the  government's  needs  at  the  best  price 
(now  and  in  the  future); 

to  promote  innovation  and  growth  in  American  industry;  and 
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to  promote  the  social  and  economic  development  of  certain  segments  of 
American  society. 

The  government  attempts  to  meets  its  goals  with  certain  objectives.  These 
objectives  are  derived  from  the  goals  and  the  fundamental  nature  of  how  the 
government  operates.  The  objectives  are: 

Competition.  The  government  recognizes  that  competition  causes  offerors  to 
lower  price  and  increase  quality  in  order  to  win  contracts.   Competition  is  the 
primary  means  of  attaining  economy  and  efficiency  in  satisfying  the  needs  of 
the  government.  The  government  recognizes  that  new  sources  must  be 
considered  to  increase  the  number  of  options,  to  stimulate  new  ideas  by 
providing  an  accessible  market,  and  to  be  fair  to  all  businesses  interested  in 
selling  to  the  government. 

Fairness.  In  order  to  achieve  meaningful  competition,  the  government  must 
conduct  procurements  fairly.  By  offering  all  vendors  and  new  ideas  a  fair 
chance,  the  government  encourages  growth. 

Promotion  of  small,  minority-owned,  woman-owned,  and  disadvantaged 
businesses.  The  government  recognizes  that  the  socio-economic  development 
of  these  groups  is  to  the  advantage  of  the  country.  This  objective  is  closely 
related  to  the  previous  objective. 

Given  these  diverse  goals  for  the  procurement  process  and  the  myriad  individual 
situations,  it  is  possible  for  conflicts  to  arise  in  the  process. 

B.2.   BASIC  FIP  PROCUREMENT  PRACTICES 

The  administration  of  these  goals  and  objectives  in  FIP  procurement  is  governed  by 
laws  and  regulations  which  are  implemented  in  the  FAR,  the  FIRMR,  and  agency 
regulations.  While  these  sources  contain  much  more  information,  the  following  is  a 
brief  list  of  fundamental  practices. 

GSA  Responsibility.  GSA  has  authority  for  the  management  and  oversight  of  FIP 
procurement.   Agencies,  however,  are  responsible  for  defining  their  requirements. 
GSA  exercises  its  authority  in  a  number  of  ways: 

Delegation  of  Procurement  Authority  (DPA).  GSA  exercises  its  authority 
through  the  use  of  DPAs.  Without  a  DPA,  an  agency  cannot  acquire  FIP 
resources.  There  are  three  types  of  delegations:  regulatory,  specific  agency, 
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and  specific  acquisition.  GSA  can  withdraw  or  limit  DPAs  and  can  refuse  to 
grant  DPAs  until  procurements  conform  to  GSA  standards. 

GSA  Reviews.  GSA  conducts  periodic  reviews  to  assess  how  agencies  are 
acquiring  and  managing  FIP  resources. 

General  Services  Board  of  Contract  Appeals  (GSBCA).  The  GSBCA  was 
created  by  the  Competition  in  Contracting  Act  of  1984  to  hear  protests 
relating  to  FIP  procurement.   (Contract  cases  can  also  be  heard  by  the 
General  Accounting  Office,  the  procuring  agency,  or  the  courts.)  The 
GSBCA  can  uphold  or  overturn  procurements  and  can  suspend  an  agency's 
DPA. 

Vendors  can  protest  a  specification  or  action  of  the  government  relating  to  a 
particular  procurement  if  the  protest  meets  certain  administrative  and  legal 
constraints.   Vendors  can  protest  that  a  specification  is  restrictive,  that  the 
agency  does  not  require  a  certain  specification,  or  that  the  government  was 
unfair  or  did  not  follow  its  procedures  correctly.  The  protesting  of 
specifications  has  caused  the  government  to  not  only  identify  requirements, 
but  also  justify  them. 

A  protest  can  delay  a  procurement  for  months  or  years  and  can  result  in  an 
agency  having  to  amend  the  solicitation  or,  in  a  worse  case,  issue  a  new 
solicitation.   A  solicitation  that  is  well  justified  by  the  supporting 
documentation  is  essential  to  minimize  protests  and  to  lessen  their  duration. 

Full  and  Open  Competition.  The  Competition  in  Contracting  Act  of  1984  requires 
the  government  to  use  full  and  open  competition.   Sometimes  procurement  initiators 
are  confused  about  the  definition  of  full  and  open  competition.   Full  and  open 
competition  is  achieved  when  all  responsible  sources  are  given  the  opportunity  to 
submit  a  proposal  and  be  considered. 

Full  and  open  competition  is  not  necessarily  achieved  when  there  is  more  than  one 
source.   Consideration  of  three  products  does  not  mean  that  the  government  can 
refuse  to  consider  a  fourth  responsible  source.  The  government  must  consider 
products  from  all  responsive  and  responsible  sources.   (See  glossary  for  definitions 
of  responsive  and  responsible.) 

Note:  There  are  exceptions  to  full  and  open  competition  that  are  described  in 
FAR  6.3. 
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B.3.  PROCUREMENT  CYCLE  FROM  THE  PROCUREMENT  INITIATOR'S 
POINT  OF  VIEW 


The  procurement  initiator  is  the  sponsor  or  program  manager  who  represents  the 
organization  that  needs  the  FIP  resources.  This  person  often  becomes  the 
contracting  officer's  (technical)  representative  (COR  or  COTR)  after  award.  The 
procurement  cycle  is  the  progression  of  stages  in  the  process  of  acquiring  property 
or  services.  From  the  procurement  initiator's  point  of  view,  the  procurement  cycle 
consists  of  four  stages:   planning,  solicitation,  source  selection,  and  contract 
administration  and  closeout. 

Planning.   Procurement  planning  can  be  divided  into  two  subsections:  general 
planning  and  the  specific  planning  for  a  procurement.  Part  7  of  the  FAR  provides 
additional  guidance  on  acquisition  planning. 

Solicitation.   Solicitation  refers  to  the  process  of  asking  vendors  for  proposals  (also 
called  offers)  or  bids.   This  guideline  addresses  the  Request  for  Proposals  (RFP) 
because  it  is  the  most  common  and  most  complex  form  of  solicitation.  There  are 
other  methods,  such  as  the  Invitation  for  Bids  (DFB)  or  Request  for  Quotes  (RFQ). 
The  ideas  in  this  guideline  can  be  used  for  all  types  of  solicitations. 

An  RFP  has  13  sections,  which  are  generally  referred  to  by  letter.  Figure  3  lists  the 
sections.   Appendix  A  contains  a  chart  describing  the  sections. 


Letter        Section  Title 

A  Solicitation/Contract  Form  -  Standard  Form  33 

B  Supplies  or  Services  and  Prices  and  Costs 

C  Descriptions/Specif icat ions /Work  Statement 

D  Packaging  and  Marking 

E  Inspection  and  Acceptance 

F  Deliveries  or  Performance 

G  Contract  Administration  Data 

H  Special  Contract  Requirements 

I  Contract  Clauses 

J  List  of  Attachments 

K  Representations,   Certifications,   and  Other 

Statements  of  Offerors  or  Quoters 

L  Instructions,   Conditions,   and  Notices  to  Offerors 

M  Evaluation  Factors  for  Award 


Figure  3.     RFP  Sections. 
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Source  Selection.    Source  selection  is  the  process  of  evaluating  offers  against 
criteria  stated  in  the  solicitation  and  selecting  the  offer  that  best  meets  the 
government's  requirements.   Source  selection  can  involve  various  forms  of 
interactions  with  offerors  including  negotiations,  clarification  requests,  discussions, 
and  best  and  final  offers  (BAFOs).   It  can  also  include  performance  and  capability 
testing.  In  addition,  the  government  must  notify  unsuccessful  offerors  and  debrief 
them,  if  requested. 

Contract  Administration  and  Closeout.  Contract  administration  refers  to  the 
management  of  the  contract,  including  inspection  and  acceptance  of  deliverables  and 
modification  of  the  contract.   It  occurs  after  actual  contract  award.  Contract 
administration  duties  are  shared  by  the  contracting  officer  and  the  contracting 
officer's  technical  representative  (COTR).  Closeout  is  the  action  that  is  taken  when 
performance  under  the  contract  is  completed. 

Procurement  Cycle  Figure.  A  figure  showing  the  FIP  procurement  cycle  from  the 
procurement  initiator's  point  of  view  is  presented  in  figure  4.   Chapter  three  will 
expand  on  the  figure  by  incorporating  computer  security  activities.  Procurement 
initiators  who  are  unfamiliar  with  the  procurement  cycle  should  obtain  additional 
guidance  from  their  procurement  office. 

Many  of  the  actions  taken  by  the  contracting  officer  are  not  reflected  in  this  figure. 
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PROCUREMENT  CYCLE 
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Figure  4.     Procurement  Cycle. 
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CHAPTER  III 


INCORPORATING  COMPUTER  SECURITY  INTO  THE  PROCUREMENT 

CYCLE 


To  effectively  include  computer  security  in  the  procurement  process  it  must  be 
integrated  into  the  procurement  cycle  from  its  inception.   This  guideline  focuses  on 
the  computer  security  components  of  the  procurement  cycle.   Sufficient  information 
about  the  procurement  cycle  is  included  to  allow  a  person  not  familiar  with  the 
procurement  process  to  understand  the  chapter.  This  chapter  does  not  provide  a 
complete  description  of  the  procurement  process.  (See  the  FAR  and  the  FIRMR  for 
detailed  procurement  information.) 

A.  PARTICIPANTS 

There  are  many  participants  who  can  have  a  computer  security  or  oversight  role  in 
procurements  depending  on  the  nature  and  scope  of  the  system.   These  participants 
are  listed  both  by  type  of  role  and  by  functional  title.  The  names  for  the  roles  and 
titles  will  vary  in  different  organizations.  Each  of  these  does  not  necessarily  provide 
input  in  every  phase.   For  instance,  support  contractors  and  vendors  are  restricted 
from  participating  in  some  phases.  The  determination  of  which  participants  need  to 
be  consulted  is  as  unique  as  the  procurement. 

The  list  of  participating  groups  and  offices  below  is  not  all  inclusive,  but  does 
represent  many  of  the  functions  that  can  impact  security. 

Procurement  Initiator/Sponsor 
Functional  Manager/Owner  of  data 
Users 

Procurement/Contracts 
Certification/Accreditation 
Computer  Security 

Quality  Assurance/Quality  Control/Safety 
Legal 

Information  Resources  Management 

Design/Engineering 

Budget 

Audit/Internal  Control 

Physical/Personnel  Security 

Facilities/Logistics 

Support  Contractors/Consultants 

Manuf acturers/Suppliers/V  endors 
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The  length  of  the  list  is  indicative  of  the  difficulty  of  managing  and  acquiring  FIP 
resources.   It  is  vital  that  these  groups  work  together  to  ensure  that  important 
aspects  of  the  procurement  are  addressed. 

As  with  any  acquisition,  it  is  important  to  involve  the  contracting  officer  as  early  as 
possible,  preferably  in  the  planning  stage. 

B.   COMPUTER  SECURITY  IN  THE  PROCUREMENT  CYCLE 

The  purpose  of  this  section  is  to  define  steps  that  will  integrate  computer  security 
into  the  procurement  cycle.  The  section  explains  each  of  the  computer  security 
steps  of  each  phase  of  the  procurement  cycle.   During  the  procurement  cycle,  the 
technical  and  security  requirements  will  be  advanced  together. 

Figure  6,  Computer  Security  in  the  Procurement  Cycle,  located  at  the  end  of  this 
chapter,  illustrates  how  security  fits  into  the  procurement  cycle.   It  expands  on 
figure  4  in  chapter  two  and  maps  security-related  activities  to  the  procurement 
activities  already  being  performed.   This  chapter  will  explain  each  computer  security 
activity  in  figure  6. 

The  computer  security  steps  in  this  section  describe  analyses  and  processes  to  be 
accomplished.  These  steps  define  a  conceptual  framework  for  computer  security 
planning  during  the  procurement  cycle.  This  framework  is  intended  to  be  used  as 
an  example;  it  is  not  a  definitive  methodology.  The  framework  contains  descriptions 
of  a  core  set  of  planning  considerations  that  will  lead  to  the  production  of  computer 
security  acquisition  specifications,  as  required  by  OMB  Circular  A- 130.  Agencies 
can  use  other  methodologies  or  modify  the  one  presented  here. 

B.l.  PLANNING 

The  first  phase  in  the  procurement  cycle  is  planning.  Planning  is  normally  divided 
into  General  Planning  and  Procurement  Specific  Planning.  General  planning 
involves  planning  on  an  organizational  level.  This  section  addresses  the  needs 
determination  component  of  general  planning.  Procurement  specific  planning 
involves  planning  for  a  specific  system  or  acquisition.   In  this  document, 
procurement  specific  planning  is  further  broken  down  into  the  Requirements  Analysis 
and  Other  Planning  Components. 
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B.l.a.   Needs  Determination 

The  needs  determination  is  an  initial  definition  of  a  problem  that  might  be  solved 
through  automation.   It  is  also  called  a  requirements  determination.  Traditional 
components  of  the  needs  determination  are  a  basic  system  idea,  a  preliminary 
requirements  definition,  feasibility  assessment,  technology  assessment,  and  some  form 
of  approval  to  further  investigate  the  problem. 

A  need  may  have  been  determined  from  strategic  or  tactical  planning.  The  following 
definitions  are  from  the  GSA  publication  Acquisition  of  Information  Resources: 
Overview  Guide. 

Strategic  planning  defines  the  major  information  resources  activities  and  types 
of  information  required  by  the  organization  and  produces  a  high-level  strategy 
for  pursuing  the  organization's  information  resource  needs. 

Tactical  planning  is  the  identification,  scheduling,  management,  and  control  of 
tasks  necessary  to  accomplish  individual  activities  identified  in  the  strategic 
plan. 

Acquisition  planning  can  only  begin  after  an  agency  has  determined  that  a  need 
exists.   The  needs  determination  phase  is  very  high-level  in  terms  of  functionality. 
No  specifics  of  a  system  are  defined  here.  The  idea  for  a  new  or  substantially 
upgraded  system  and  the  feasibility  of  the  idea  are  explored.   During  this  early 
phase  of  the  acquisition,  the  definition  of  the  security  requirement  should  begin  with 
the  preliminary  sensitivity  assessment. 

Preliminary  sensitivity  assessment.  The  preliminary  sensitivity  assessment  should 
result  in  a  brief  qualitative  description  of  the  basic  security  needs  of  the  system. 
These  should  be  expressed  in  terms  of  the  need  for  integrity,  availability,  and 
confidentiality. 

This  does  not  require  an  elaborate  sensitivity  analysis  scheme,  but  does  require  an 
assessment  of  the  significance  of  the  systems.   Legal  implications,  federal  policy, 
agency  policy,  and  the  functional  needs  of  the  system  help  determine  its  sensitivity. 
Factors  including  the  importance  of  the  system  to  the  agency  mission  and  the 
consequences  of  unauthorized  modification,  unauthorized  disclosure,  or  unavailability 
of  the  system  or  data  should  be  considered  when  assessing  sensitivity. 
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B.l.b.   Requirements  Analysis 

The  requirements  analysis  is  an  indepth  study  of  the  need.   It  draws  on  the  work 
done  during  the  needs  determination  and  develops  it.  Requirements  analyses  are 
required  by  FIRMR  Part  201-20.102: 

Agencies  shall  establish  and  document  requirements  for 
FIP  (federal  information  processing)  resources  by 
conducting  a  requirements  analysis  commensurate  with  the 
size  and  complexity  of  the  need. 

The  following  computer  security  components  should  be  included  in  a  requirements 
analysis: 

Analysis  of  integrity,  availability,  and  confidentiality  requirements; 

Update  sensitivity  assessment; 

Analysis  of  the  level  of  assurance  required; 

Planning  phase  risk  analysis;  and 

Preliminary  certification/accreditation  plan. 

As  stated  above,  these  analyses  present  a  conceptual  framework  for  computer 
security  planning.  They  are  intended  to  be  used  as  a  guide,  example,  or  roadmap. 
Other  methods  of  computer  security  planning  are  acceptable. 

While  this  section  presents  the  computer  security  components  of  the  requirements 
analysis  in  sequential  fashion,  they  can  be  done  in  a  different  order.  For  more 
complex  systems,  they  will  need  to  be  done  cyclically  until  all  of  the  components 
work  together.   For  smaller  acquisitions,  all  of  the  components  can  be  combined  into 
one  analysis.   Figure  5  at  the  end  of  this  section  shows  how  the  computer  security 
components  of  the  requirements  analysis  phase  can  interact. 

Analysis  of  integrity,  availability,  and  confidentiality  requirements.  Computer 
security  is  defined  as  the  process  for  determining,  cost-justifying,  and  applying  the 
technological  safeguards  and  managerial  procedures  to  protect  information  processing 
resources,  including  data,  hardware,  software,  telecommunications,  and  related 
services.   In  practice,  the  need  for  protection  is  expressed  in  terms  of  the  need  for 
integrity,  availability,  and  confidentiality.  Integrity  can  be  looked  at  from  several 
perspectives.   From  a  user's  or  application  owner's  perspective,  integrity  is  a  quality 
of  data  that  is  based  on  attributes  such  as  accuracy  and  completeness.  From  a 
systems  or  operations  perspective,  integrity  is  the  quality  of  data  that  it  is  only 
changed  in  an  authorized  manner  or  that  the  system/software/process  does  what  it  is 
supposed  to  do  and  nothing  more.  Like  integrity,  availability  also  has  a  multi-part 
definition.   Availability  is  the  state  when  data  or  a  system  is  in  the  place  needed  by 
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the  user,  at  the  time  the  user  needs  it,  and  in  the  form  needed  by  the  user. 
Confidentiality  is  the  privacy,  secrecy,  or  nondisclosure  of  information  except  to 
authorized  individuals. 

The  first  step  in  the  analysis  is  to  determine  what  the  protection  requirements  are. 
The  analysis  will  be  built  upon  the  sensitivity  assessment  done  during  the  needs 
determination,  but  will  be  more  indepth  and  specific. 

This  process  should  include  an  analysis  of  laws  and  regulations  such  as  the  Privacy 
Act,  the  Federal  Manager's  Financial  Integrity  Act,  the  Computer  Security  Act, 
OMB  circulars,  agency  enabling  acts,  and  other  legislation  and  federal  regulations 
which  define  baseline  security  requirements.   After  a  review  of  mandated 
requirements,  agencies  should  consider  functional  and  other  security  requirements. 

At  this  level,  as  opposed  to  the  needs  determination  level,  the  analysis  should  be 
system  specific.  The  legal,  functional,  and  other  computer  security  requirements 
should  be  stated  in  specific  terms.   For  complex  systems,  this  will  require  more  than 
one  iteration  of  the  requirements  analysis  components. 

Since  most  systems  have  at  least  minimal  integrity  and  availability  requirements, 
care  should  be  taken  to  address  these  areas  clearly.   Computer  security  is  more  than 
confidentiality.   Even  systems  with  no  confidentiality  requirement  need  security  to 
meet  integrity  and  availability  requirements. 

Update  Sensitivity  Assessment.  After  completing  the  analysis  of  integrity, 
availability,  and  confidentiality  requirements,  the  sensitivity  assessment  should  be 
updated  based  on  the  results. 

Analysis  of  the  level  of  assurance  required.  The  correct  and  effective  use  of 
computer  security  controls  is  a  fundamental  building  block  of  system  security. 
Assurance  is  the  degree  to  which  the  purchaser  of  a  system  knows  that  the  security 
features  and  procedures  being  acquired  will  operate  correctly  and  will  be  effective  in 
the  purchaser's  environment. 

Obtaining  assurance  can  be  quite  difficult  because  assurance  can  be  expensive  and 
can  be  hard  to  quantify.  This  analysis  needs  to  address  how  much  confidence  is 
needed  that  the  computer  security  will  work  correctly  and  effectively.  The  analysis 
should  be  based  on  both  legal  and  functional  requirements  and  will  be  the  basis  for 
determining  how  much  and  what  kinds  of  assurance  are  required.  This  assurance 
analysis  will  lead  directly  to  the  evaluation  plan  which  will  be  developed  in  the 
solicitation  phase.   It  can  also  be  used  to  help  determine  appropriate  acceptance 
criteria. 
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As  with  other  aspects  of  security,  it  is  important  to  remember  that  the  goal  is  cost- 
effective  security,  not  absolute  security.  Absolute  security  is  virtually  impossible  to 
attain  and  can  be  cost  prohibitive  in  terms  of  system  usefulness  and  dollars. 

There  are  many  techniques  for  obtaining  assurance.  For  a  further  discussion, 
including  a  list  of  assurance  methods,  see  Appendix  B. 

Review  by  Other  Functional  Groups.  Depending  on  the  size  and  scope  of  the 
system,  a  team  or  group  of  participants  from  the  functional  groups  described  in  the 
beginning  of  this  chapter  may  be  useful.  Even  for  small  systems,  it  may  be  helpful 
to  get  the  assistance  of  the  computer  security  staff.  These  functional  groups  may 
have  insight  into  the  integrity,  availability,  confidentiality  and  assurance 
requirements.   Getting  these  groups  involved  early  in  the  planning  process  is 
important  since  it  may  result  in  reduced  life  cycle  cost  because  it  is  easier  to  change 
requirements  in  the  early  stages. 

Planning  Phase  Risk  Analysis.  The  planning  phase  risk  analysis  is  a  critical  step. 
It  is  used  to  determine  what  types  of  controls  will  be  cost-effective  and  forms  the 
basis  for  determining  mandatory  and  desirable  specifications.  OMB  Circular  A- 130 
requires  a  risk  analysis  prior  to  the  approval  of  design  specifications.  In  addition,  a 
risk  analysis  can  provide  justification  in  case  specifications  are  protested. 
The  planning  phase  risk  analysis  will  not  necessarily  be  a  large  and  complex 
document.  The  analysis,  like  other  risk  analyses,  should  consider  assets,  threats  to 
the  assets,  potential  vulnerabilities,  and  what  can  be  done  to  reduce  vulnerabilities. 
The  planning  phase  risk  analysis  should  take  into  consideration  what  controls  already 
exist  and  their  effectiveness.  The  planning  phase  risk  analysis  will  probably  require 
participation  by  the  other  functional  groups. 

The  planning  phase  risk  analysis  will  use  input  from  the  analysis  of  integrity, 
availability,  and  confidentiality  requirements  as  the  basis  for  determining  the  value 
of  information  assets  and  the  impact  of  security  failures.   The  selection  of 
appropriate  types  of  safeguards  should  take  into  consideration  the  results  of  the  level 
of  assurance  analysis.  The  planning  phase  risk  analysis,  in  turn,  may  point  out 
deficiencies  in  the  analysis  of  integrity,  availability  and  confidentiality  requirements 
or  the  level  of  assurance  analysis  by  demonstrating  the  logical  conclusion  of  the 
analyses. 

Further  information  on  the  planning  phase  risk  analysis  is  contained  in  Appendix  C. 

Review  by  certification  and/or  accreditation  official.  OMB  Circular  A- 130 
requires  that  systems  be  approved  for  processing  based  on  the  adequacy  of  the 
safeguards.  This  process  is  referred  to  as  both  certification  and  accreditation  in 
different  agencies.  The  approval  is  made  by  either  the  program  manager  or  a 
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designated  approving  official.  Since  this  official  has  responsibility  for  accepting  the 
risk,  it  is  prudent  to  get  approval  of  the  certification  and/or  accreditation  approach. 
The  certification  and/or  accreditation  approach  should  address  the  vulnerabilities  that 
may  exist  in  the  system.  The  approving  authority  can  advise  the  acquisition  team  if 
the  risks  appear  to  be  acceptable.  It  is  easier  to  incorporate  requirement  changes 
during  the  planning  stage  of  a  system  acquisition  than  during  the  solicitation,  source 
selection,  or  contract  administration  stages. 

The  acquisition  team  and  the  approving  authority  should  also  discuss  what  forms  of 
assurance  the  approving  authority  needs  to  make  a  decision.  This  can  include 
system  tests  and  other  items  that  need  to  be  addressed  in  the  solicitation.  Assurance 
is  discussed  in  Appendix  B. 

In  addition,  the  procurement  initiator  and  the  approving  authority  should  discuss  how 
changes  to  the  system  and  its  environment  will  be  addressed.  The  possibility  of  a 
security  working  group  should  be  discussed.  The  group  can  consist  of  various  types 
of  people  such  as  application  sponsors;  system,  security,  or  database  administrators; 
security  officers  or  specialists;  and  system  or  application  analysts.  Section  IV.F 
presents  specifications  for  this  group. 

For  further  information  on  certification  and  accreditation  see  FIPS  PUB  102 

Guideline  for  Computer  Security  Certification  and  Accreditation. 

Cyclical  Nature  of  the  Process.  As  stated  in  the  introduction,  these  requirements 
analysis  sub-components  may  need  to  be  performed  cyclically.  The  components 
inter-relate  and  build  on  each  other.   Depending  on  the  size  and  complexity  of  the 
system,  these  components  may  be  performed  many  times  as  ideas  become  refined 
and  focused.  The  flow  model  on  the  next  page  (fig.  5)  shows  how  the  computer 
security  components  of  the  requirements  analysis  phase  of  the  procurement  cycle  can 
work  together. 
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FLOW  MODEL  FOR  SECURITY 
REQUIREMENTS  ANALYSIS 


Figure  5.   Flow  Model. 
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B.l.c.   Other  Planning  Components 

There  are  several  other  parts  of  the  planning  process  that  will  incorporate  computer 
security  in  their  cycles: 

feasibility  study, 

system  cost-benefit  analysis, 

software  conversion  study, 

analysis  of  technical  alternatives,  and 

market  surveys. 

The  feasibility  study  should  also  look  at  the  computer  security  of  the  system.  If 
security  is  not  considered  during  the  feasibility  study,  then  it  is  possible  for  a 
computer  system  to  be  acquired  for  which  there  is  no  cost-effective  security  solution. 

The  cost-benefit  analysis  should  use  input  from  the  planning  phase  risk  analysis.  If 
the  cost-benefit  analysis  does  not  consider  security,  then  it  is  possible  for  it  to  favor 
a  system  which  will  later  require  security  upgrades  (which  could  be  expensive).  In 
addition,  it  could  favor  a  system  with  unnecessary  exposures  to  traumatic  failures. 

The  software  conversion  study,  which  examines  the  cost  of  re-establishing  software 
on  a  new  hardware  or  software  base,  should  include  the  cost  of  re-establishing  the 
desired  degree  of  computer  security  on  the  new  system  and  maintaining  security 
during  the  transition. 

The  analysis  of  technical  alternatives  should  rate  the  alternatives  against  their  ability 
to  meet  all  the  requirements  including  computer  security. 

The  market  surveys,  which  may  include  Requests  for  Comment  (RFCs)  or  Requests 
for  Information  (RFIs),  should  include  the  computer  security  requirements. 

At  the  end  of  the  planning  phase,  the  government  will  have  determined  the 
requirements  and  the  best  ways  to  achieve  them.  This  will  include  a  decision  on 
whether  a  requirement  can  be  met  through  acquisition  or  in-house  development. 
Many  systems  combine  these  methods.   Since  the  planning  phase  looks  at  the  whole 
system,  the  computer  security  and  other  functional  requirements  should  have  been 
adequately  addressed  to  allow  acquisition  of  components  while  maintaining  system 
integrity. 

Many  agencies  have  an  approval  process,  which  may  include  computer  security,  at 
the  end  of  the  planning  phase.  The  approval  can  be  used  to  see  if  the  procurement 
incorporates  a  rational  risk-based  approach  to  security  planning.   (It  is  not  necessary 
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for  the  procurement  initiator  to  have  exactly  followed  the  steps  outlined  in  this 
special  publication;  other  approaches  can  be  used.) 

B.2.  SOLICITATION 

The  second  phase  in  the  procurement  cycle  is  the  solicitation  phase.  This  covers  the 
development  and  issuance  of  the  request  for  proposals  (RFP)  and  the  receipt  of 
proposals. 

All  considerations  surrounding  the  acquisition  of  the  product  or  service  must  be 
addressed  in  the  solicitation.  This  includes  the  description  of  what  is  being 
acquired;  how  it  will  be  acquired;  how  it  will  be  evaluated,  tested,  and  accepted; 
and  how  the  contract  will  be  administered.   Although  the  actual  evaluation  of 
proposals  or  the  administration  of  the  contract  happens  in  later  phases,  these  areas 
must  be  addressed  now. 

An  RFP  is  designed  to  allow  the  government  to  make  a  best  value  decision  based 
on  an  offeror's  proposal.   One  of  the  strengths  of  the  RFP  process  is  the  flexibility 
it  provides  the  government  and  the  offeror  to  negotiate  a  contract  that  best  meets  the 
government's  needs. 

The  government  can  identify  needed  computer  security  features,  procedures,  and 
assurances  in  many  ways.   An  RFP  can  be  a  flexible  document  which  allows  for 
substantial  creativity.   Guidance  on  procurement  alternatives  should  be  obtained  from 
the  agency  procurement  office  or  the  contracting  officer. 

Because  of  the  flexibility,  it  is  impossible  to  address  precise  mapping  of  the 
computer  security  considerations  into  the  uniform  solicitation.  The  procurement 
initiator  needs  to  decide  how  the  computer  security  considerations  will  be  met  given 
the  many  options  an  RFP  provides. 

This  guideline  explains  some  of  the  considerations  for  developing  a  statement  of 
work/specification  and  provides  general  guidance  about  evaluation,  testing,  and 
acceptance  of  the  computer  security  features.  The  procurement  initiator  must  decide 
how  a  given  feature,  procedure,  or  assurance  fits  in  the  RFP.  In  addition,  this 
guideline  provides  guidance  about  clauses. 
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B.2.a.   Specifications  and  Work 

The  statement  of  work  (SOW)  or  specification  is  based  on  the  requirements  analysis. 
This  section  describes  two  types  of  sources  for  computer  security  specifications: 
general  specifications  and  federally  mandated  specifications. 

Security  requirements  can  be  included  in  the  SOW  as  specifications,  tasks,  labor, 
work,  level  of  effort,  etc.  The  procurement  initiator  should  concentrate  on  what  is 
required  and  work  with  the  contracting  officer  to  determine  how  to  ask  for  it. 

General  Specifications 

There  are  many  sources  of  general  computer  security  specifications.  NIST  guidance 
documents,  such  as  this  one,  and  guidance  from  other  federal  agencies  and 
commercial  groups  are  some  sources.  The  indexes  to  NIST  documents  are 
referenced  below  and  are  updated  periodically.   Also,  DoD  has  extensive  material 
that  can  be  used  for  guidance.   The  Trusted  Computer  Systems  Evaluation  Criteria 
(TCSEC)  or  "Orange  Book"  is  a  DoD  standard  that  defines  many  computer  security 
specifications.   The  TCSEC  is  a  DoD  standard  but  NOT  a  federal  government 
standard.   There  are  also  specifications  in  other  DoD  and  other  agency  computer 
security  guidelines.   Commercial  sources  and  trade  organizations  also  publish  general 
computer  security  specifications. 

These  computer  security  documents  can  be  reviewed  for  applicability  to  the 
system(s)  being  procured.  They  may  represent  areas  that  were  overlooked  and  they 
can  save  time  since  they  provide  already  prepared  SOW  language.   Care  should  be 
taken  when  selecting  features,  procedures,  and  assurances  from  these  sources.  The 
items  may  be  grouped  based  on  interdependencies  between  the  items.   It  is 
necessary  to  understand  the  features,  procedures,  assurances,  and  groupings  before 
specifying  them  separately. 

Each  specification  must  be  justified  from  the  requirements  analysis,  specifically  from 
the  planning  phase  risk  analysis.   Safeguards  recommended  by  a  general  source 
should  be  considered,  but  they  should  not  be  included  in  an  RFP  if  the  risk  analysis 
does  not  support  them. 

Federally  Mandated  Specifications 

There  are  other  sources  of  computer  security  (and  nonsecurity)  specifications  which 
are  required  by  law  to  be  included  in  the  RFP.  These  are  often  referred  to  as 
directed  specifications.   All  federal  agencies  must  require  that  systems  comply  with 
applicable  FIPS  PUBS  and  Federal  Standards.  Executive  agencies  must  comply  with 
OMB  Circular  A- 130.  There  are  also  agency- specific  directed  specifications,  which 


29 


are  official  policies  issued  with  the  concurrence  of  agency  legal  and  procurement 
officials. 

Directed  specifications  must  be  incorporated  in  an  RFP  if  the  system  being  acquired 
matches  the  criteria  in  the  directed  specification.   It  is  very  important  to  be  aware  of 
directed  specifications.   If  specifications  in  an  RFP  conflict  with  directed 
specifications,  a  waiver  must  be  obtained. 

The  following  publications  contain  lists  of  standards  including  FIPS  PUBS  and 
Federal  Standards: 

NIST  Publications  List  58  -  Federal  Information  Processing  Standards 
Publications  (FIPS  PUBS)  Index 

NIST  Publication  List  88  -  Computer  Systems  Publications 

NIST  Publications  List  91  -  Computer  Security  Publications 

GSA  Handbook  "Federal  ADP  and  Telecommunications  Standards  Index" 

Ordering  information  for  NIST  publications  is  printed  on  the  inside  back  cover  of 
this  document.  The  GSA  Handbook  is  available  from  the  Government  Printing 
Office. 

Another  source  for  directed  specifications  is  the  Model  Framework  for  Management 
Control  Over  Automated  Information  Systems  published  jointly  by  the  President's 
Council  on  Management  Improvement  and  President's  Council  on  Integrity  and 
Efficiency.  This  document  provides  guidance  on  requirements  for  control  imposed 
by  the  Federal  Manager's  Financial  Integrity  Act  of  1982,  the  Privacy  Act  of  1974, 
and  OMB  Circulars  A-123,  A-127,  and  A-130.   The  Framework  states,  "...federal 
managers  are  expected  to: 

Understand  the  55  control  requirements  identified  in  the  report;  and 
Implement  a  program  that  demonstrates  compliance  with  the  requirements." 

It  is  incumbent  on  the  procurement  initiator  to  know  what  federal  standards  apply  to 
the  system(s)  being  procured.   Many  people  erroneously  feel  that  this  is  the 
responsibility  of  the  contracting  officer.   These  are  technical  issues  and  are, 
therefore,  the  responsibility  of  the  procurement  initiator. 

B.2.b.  Evaluation 

Evaluation  is  the  process  of  determining  if  an  offer  meets  the  minimum  requirements 
described  in  the  RFP  and  an  assessment  of  the  offeror's  ability  to  successfully 
accomplish  the  prospective  contract.  This  involves  a  technical  analysis  of  the  merits 
of  a  proposal.   As  part  of  the  solicitation  phase,  the  procurement  initiator,  working 
with  the  contracting  officer,  develops  an  evaluation  plan  to  determine  the  basis  for 
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the  evaluation  and  how  it  will  be  conducted.  The  evaluation  itself  is  performed 
during  the  source  selection  phase  of  the  procurement. 

Developing  an  Evaluation  Plan. 

When  evaluating  computer  security  features,  it  can  be  difficult  to  assess  if  the  offer 
meets  the  minimum  requirements  or  can  successfully  accomplish  the  prospective 
contract.    Therefore,  offerors  should  have  to  provide  assurance  to  the  government 
that  hardware  and  software  claims  regarding  computer  security  features  are  true  and 
that  the  offeror  can  provide  the  proposed  services.   Since  computer  security,  like 
other  parts  of  computer  systems,  is  a  complex  and  important  subject,  the  offeror's 
assertions  may  not  provide  sufficient  assurance.   Appendix  B  further  discusses 
assurance  and  presents  ideas  for  how  the  government  can  obtain  it.   In  addition, 
section  IV.D  provides  descriptions  of  documentation  that  can  be  used  for  assurance 
in  the  evaluation  phase,  such  as  the  offeror's  strategy  for  security. 

How  assurances  are  provided  may,  in  fact,  determine  the  ability  of  the  government 
to  adequately  assess  them.   Security  personnel  need  to  be  sure  they  are  asking  for 
the  information  they  really  need.   If,  after  award,  the  government  determines  that 
more  assurance  is  required,  the  government  may  be  liable  for  additional  costs. 

The  determination  of  how  the  offerors  will  be  required  to  provide  assurance  should 
be  considered  when  developing  the  evaluation  plan.  This  plan  will  be  used  to  help 
develop  sections  of  the  RFP  which  provide  instructions  to  the  offerors  and 
information  about  how  the  proposals  will  be  evaluated  and  how  source  selection  will 
be  performed. 

As  part  of  this  process,  a  determination  of  security  acceptance  testing  should  be 
made.  It  may  be  important  to  coordinate  evaluation  and  acceptance  to  effectively 
manage  the  security  review  and  testing  of  proposals  and  deliverables. 

Items  to  Consider  in  the  Evaluation  Plan. 

The  remainder  of  this  section  presents  ideas  to  assist  with  the  development  of  the 
computer  security  aspects  of  the  evaluation  plan.   One  aspect  of  the  evaluation  plan 
is  selecting  evaluation  team  members.   Section  III.B.3,  Source  Selection,  discusses 
some  of  the  roles  and  duties  of  the  evaluation  team. 

When  the  evaluation  plan  is  developed,  keep  in  mind  that  alternatives  may  conflict 
with  each  other.   For  example,  features  which  provide  computer  security  can  conflict 
with  those  that  provide  ease  of  use.  The  government  must  make  it  clear  how 
offerors  should  propose  different  configurations  and  present  conflicting  options  and 
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trade-offs.   However,  care  should  be  taken  to  keep  proposal  size  manageable  to 
facilitate  review  and  to  keep  proposal  preparation  costs  down. 

When  computer  security  is  important  in  the  acquisition,  it  must  be  addressed  in  the 
evaluation  criteria  so  that  offerors  will  know  that  it  is  important  to  the  government. 
Offerors  look  at  the  RFP  to  determine  what  the  government  considers  most 
important. 

Testing  is  one  method  of  determining  if  the  proposed  system  or  product  can  meet 
the  computer  security  requirements.   Depending  on  the  nature  of  the  system,  this  can 
be  part  of  the  proposal  evaluation,  in  the  form  of  live  test  demonstrations  or 
benchmarks,  or  it  can  be  part  of  post-award  acceptance  testing.   During  the 
evaluation  process  there  are  different  times  when  the  testing  can  occur.  There  are 
cost,  technical,  and  procurement  integrity  considerations  for  deciding  when  testing  is 
done.   In  general,  expensive  tests  should  be  kept  to  a  minimum.   This  will  help 
control  offeror  proposal  preparation  costs.   Not  only  do  expensive  proposals  limit 
competition,  but  the  costs  are  ultimately  passed  to  the  government  in  higher  contract 
costs.    Guidance  on  testing  alternatives  should  be  obtained  from  the  contracting 
officer. 

Note:   Be  sure  the  computer  system  testing,  especially  performance  testing,  is  done 
with  the  computer  security  features  enabled. 

Warning:   The  more  the  procurement  initiator  knows  about  the  market  place,  the 
easier  it  is  to  develop  an  evaluation  plan.  Proposals  cannot  be  used  for  market 
research.   The  evaluation  plan  virtually  cannot  be  changed  after  the  receipt  of 
proposals.   Additional  knowledge  learned  by  reading  proposals  cannot  be  used  to 
modify  the  evaluation  plan.  It  is  worth  the  time  to  research  what  kind  of 
alternatives  could  be  offered  so  a  scheme  that  reflects  the  true  priorities  of  the 
government  can  be  developed. 

B.2.c.   Special  Contract  Requirements 

There  are  elements  in  an  RFP  that  are  computer  security-related  but  are  not 
contained  in  the  statement  of  work  or  the  evaluation  criteria.  These  elements 
usually  address  rights,  responsibilities,  and  remedies  assigned  to  the  parties  of  the 
contract.   Many  times  such  obligations  survive  the  actual  performance  period  of  the 
contract.   Therefore,  such  elements  are  best  addressed  through  specific  contract 
clauses  or  requirements.  The  nondisclosure  of  automated  information  learned  during 
the  course  of  the  contract  is  one  example. 
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Chapter  four  addresses  clauses  as  well  as  statement  of  work  items.  The 
procurement  initiator  must  coordinate  with  the  contracting  officer  about  clauses  to  be 
added  to  an  RFP. 


B.3.   SOURCE  SELECTION 

Source  selection  is  the  determination  of  the  successful  offeror.  The  source  selection 
phase  is  based  on  the  work  done  in  the  planning  and  solicitation  phases.  This  phase 
involves  actually  evaluating  the  proposals  and  making  best  value  decisions  based  on 
the  evaluation  criteria  and  other  factors  stated  in  the  RFP.   Computer  security 
considerations  incorporated  during  the  planning  and  solicitation  phases  will  be  a  part 
of  the  evaluation  and  source  selection. 

An  individual  with  extensive  computer  security  expertise  should  be  part  of  the 
evaluation  team.  This  expert  should  be  available  to  review  the  original  proposals  as 
well  as  clarifications,  discussion  points,  and  best  and  final  offers  (BAFOs).   A  good 
review  team  is  essential  to  the  success  of  a  procurement. 

B.4.   ADMINISTRATION  AND  CLOSEOUT 

The  final  phase  in  the  procurement  life  cycle  is  administration  and  closeout. 
Computer  security  issues  for  administration  and  closeout  should  have  been  addressed 
when  developing  the  solicitation.   Two  important  computer  security  functions  during 
this  phase  are  acceptance  and  monitoring  contractor  performance. 

Acceptance.  Acceptance  refers  to  the  government's  decision  to  accept,  and 
therefore,  pay  for  a  deliverable.   The  government  should  be  careful  in  accepting 
deliverables.  Testing  by  the  government  or  an  independent  validation  and 
verification  (IV &V)  contractor  to  determine  that  the  system  does  meet  specifications 
can  be  very  useful.  This  should  include  testing  the  security  of  the  system. 

Note:   Acceptance  and  approval  to  operate  (certification  or  accreditation)  are  related, 
but  different  concepts.  The  government  normally  accepts  a  deliverable  that  meets 
the  specifications  in  the  contract.  The  approval  to  operate  is  a  separate  decision 
made  based  on  the  risks  and  advantages  of  the  system.  It  is  incorrect  to  have  the 
approval  to  operate  as  one  of  the  acceptance  criteria. 

Monitoring.  In  general,  the  government  should  plan  to  review  contractor 
performance  to  ensure  that  security  has  not  degraded  and  that  changes  in  the 
environment  and  system  that  result  in  new  threats  and  vulnerabilities  are  recognized 
and  appropriate  safeguards  put  in  place.  For  more  complex  contracts  including  more 
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than  just  purchase  of  hardware,  a  security  working  group  is  an  effective  way  to 
monitor  security.   Section  IV.F  provides  features,  procedures,  and  assurances  related 
to  contract  administration  and  closeout. 

After  award,  the  government's  requirements  should  not  change.   If  they  do,  there  are 
mechanisms  to  modify  the  contract  to  accommodate  some  changes.   However,  these 
modifications  can  be  quite  costly.   In  addition,  some  changes  may  require  separate 
procurements.   As  noted  in  the  introduction  to  this  document,  new  security  controls 
that  are  retrofitted  to  a  system  may  not  be  as  effective  as  controls  designed  into  the 
system. 
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CHAPTER  IV 


SPECIFICATIONS,  CLAUSES,  AND  TASKS 


This  chapter  provides  specifications,  tasks,  and  clauses  that  can  be  used  in  RFPs  to 
acquire  computer  security  features,  procedures,  and  assurances.   None  of  the 
specifications,  tasks,  or  clauses  are  mandatory.  They  are  intended  as  a  source  of 
general  specifications,  as  defined  in  section  III.B.2.a.  They  are  written  for  different 
types  of  acquisitions  including  purchase  of  off-the-shelf  products,  purchase  of 
integrated  systems,  development  of  applications,  and  other  computer-related  services. 

The  specifications,  tasks,  and  clauses  are  divided  into  ten  categories.  Within  each 
category  there  may  be  specifications,  tasks,  and/or  clauses  as  well  as  explanations, 
considerations,  and/or  prescriptions  about  their  use.   The  specifications,  tasks,  and 
clauses  are  printed  in  courier  typeface.    Explanations,  considerations,  and 
prescriptions  are  in  regular  type  face.  None  of  the  specifications,  tasks,  or  clauses 
should  be  used  blindly.   Each  of  them  should  be  tailored  to  meet  individual 
circumstances.  The  categories  are: 


A. 

General  Computer  Security 

B. 

Control  of  Hardware  and  Software 

C. 

Control  of  Information/Data 

D. 

Documentation 

E. 

Legal  Issues 

F. 

Contract  Administration,  End  of  Task,  Closeout 

G. 

Computer  Security  Training 

H. 

Personnel  Security 

I. 

Physical  Security 

J. 

Computer  Security  Features  in  Systems 

A  word  of  caution  on  the  use  of  subcontractors:   Ensure  applicable  computer 
security  requirements  and/or  certifications  placed  on  prime  contractors  are  also 
reflected  in  subcontracts.  This  is  called  "flowdown." 
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The  categories  above  do  not  address  tasking  language  for  specific  security  services 
such  as  having  a  risk  analysis  performed  or  having  contractors  prepare  security 
planning  documents.  Tasking  language  for  these  types  of  services  are  provided  in 
another  NIST  report,  Sample  Statements  of  Work  for  Federal  Computer  Security 
Services. 
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A.  General  Computer  Security 


In  keeping  with  OMB  Circular  A- 130,  Appendix  III,  security  responsibility  must  be 
assigned.  The  responsibility  must  rest  with  a  government  employee.  This  item 
should  be  included  to  clarify  responsibility.  If  the  contract  calls  for  computer 
security  administration,  management,  or  support,  the  delineation  of  responsibilities 
should  be  clear,  with  the  government  person  retaining  ultimate  responsibility. 

The  person  responsible  for  computer  security  is   . 

The  following  can  be  used  to  show  the  relationship  between  agency  ownership  of 
federal  information  processing  (FIP)  resources  and  contractor  use.  These  clauses 
help  establish  clear  lines  of  authority  and  responsibility. 

The  government  authorizes  the  use  of  agency  computer  resources  (list 
specific  resources  if  appropriate)  for  contractor  performance  of  the 
effort  required  by  the  statement  of  work  of  this  contract. 

The  contractor  shall  comply  with  the  requirements  of  the  agency 
computer  security  program  as  defined  by   (insert  agency  handbook, 
directives,  manuals,  etc.) 
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B.   Control  of  Hardware  and  Software 


The  government  should  consider  who  can  introduce  hardware  and  software  onto  the 
system  and  under  what  circumstances. 

Introduction  and  Change  of  Software  -  In  order  to  reduce  the  chance  of  viruses  and 
other  forms  of  malicious  code,  of  illegal  use  of  licensed  software,  and  of  software 
that  may  open  security  vulnerabilities  (such  as  operating  system  utilities  or  untested 
software  updates),  consider  restricting  contractors  by  using  the  following  types  of 
specifications  and  tasks.  These  specifications  and  tasks  could  be  used  when  the 
contractor  is  providing  a  service  such  as  running  or  maintaining  a  government 
computer  system. 

Only  licensed  software  and  in-house  developed  code  (including 
government  and  contractor  developed)    shall  be  used  on  (system 
name(s)) .     No  public  domain,   shareware,   or  bulletin  board  software 
shall  be  installed  unless  prior  written  approval  is  obtained  from 
the  contracting  officer  or  COTR. 

The  following  specification  is  fairly  restrictive.   The  alternatives  which  follow  can 
be  used  to  modify  the  specification. 

The  only  hardware  and  software  packages  that  shall  be  used  on 
(system  name ( s ) )    is   (listed  here  or  specify  section).  All 
additional  hardware  and  software  packages  proposed  for  use, 
including  upgrades,  must  be  approved  in  advance  and  in  writing  by 
the  contracting  officer  or  COTR. 

Alternatives : 

The  contractor  shall  provide  a  list  of  software  and  hardware 

changes    working  days  in  advance  of  installing  (or 

other  time  or  performance  period) . 

The  contractor  shall  provide  an  impact  analysis  for  proposed 
hardware  and  software  changes  that  includes  an  assessment  of 
possible  new  security  vulnerabilities   (include  other  assessment 
items  required)    working  days  in  advance  of  installing. 

The  contractor  shall  provide  proposed  hardware  and  software  for 
testing    working  days  in  advance  of  loading. 

The  contractor  shall  provide  proof  of  license  for  new  software. 

The  contractor  shall  maintain  a  list  of  hardware,  firmware,  and 
software  changes  throughout  the  contract.     The  contractor  shall 
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provide  this  list  to  the  government  (specify  time  frame  and/or 
at  the  end  of  the  contract) . 

If  the  contractor  is  using  their  own  software,  then  the  following  specification  can  be 
used  to  help  protect  the  government  from  buying  products  developed  with  stolen 

software. 

The  contractor  shall  provide  proof  of  license  for  all  software  used 
to  perform  under  this  contract. 

The  following  clauses  are  reprinted  from  FIRMR  Section  201-39.5202-5,  Privacy  or 
Security  Safeguards.  FIRMR  Section  201-39.1001-3  prescribes  that  these  clauses,  or 
variations  of  them,  be  used  in  solicitations  and  contracts  requiring  security  of  FIP 
resources  or  for  the  design,  development,  or  operation  of  a  system  or  records  using 
commercial  FIP  services  or  support  services.  Clause  (a),  which  addresses  ownership 
of  and  rights  to  developed  software,  should  be  coordinated  with  the  contracting 
officer  or  legal  counsel. 

(a)  The  details  of  any  safeguards  that  the  contractor  may  design  or 
develop  under  this  contract  are  the  property  of  the  government  and 
shall  not  be  published  or  disclosed  in  any  manner  without  the 
contracting  officer's  express  written  consent. 

(b)  The  details  of  any  safeguards  that  may  be  revealed  to  the 
Contractor  by  the  government  in  the  course  of  performance  under  this 
contract  shall  not  be  published  or  disclosed  in  any  manner  without 
the  contracting  officer's  express  written  consent. 

(c)  The  government  shall  be  afforded  full,    free,   and  uninhibited 
access  to  all  facilities,   installation,   technical  capabilities, 
operations,   documentation,   records,   and  data  bases  for  the  purpose 
of  carrying  out  a  program  of  inspection  to  ensure  continued  efficacy 
and  efficiency  of  safeguards  against  threats  and  hazards  to  data 
security,   integrity,   and  confidentiality. 

(d)  If  new  or  unanticipated  threats  or  hazards  are  discovered  by 
either  the  government  or  the  contractor,   or  if  existing  safeguards 
have  ceased  to  function,   the  discoverer  shall  immediately  bring  the 
situation  to  the  attention  of  the  other  party.     Mutual  agreement 
shall  then  be  reached  on  changes  or  corrections  to  existing 
safeguards  or  institution  of  new  safeguards,  with  final 
determination  of  appropriateness  being  made  by  the  government.  The 
government's  liability  is  limited  to  an  equitable  adjustment  of  cost 
for  such  changes  or  corrections,   and  the  government  shall  not  be 
liable  for  claims  of  loss  of  business,  damage  to  reputation,  or 
damages  of  any  other  kind  arising  from  discovery  of  new  or 
unanticipated  threats  or  hazards,   or  any  public  or  private 
disclosure  thereof. 
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One  option  to  modify  these  clauses  is  to  add  a  task  related  to  clause  (d): 

The  contractor  shall  provide  an  analysis  of  the  new  threat,  hazard, 
or  vulnerability  and  recommend  possible  fixes  or  safeguards. 

The  following  two  clauses  address  other  issues  in  the  use  of  government  hardware 
and  software  by  a  contractor  providing  services.  The  government  should  include  all 
restrictions  such  as  single  site  licensing,  proper  use  to  maintain  warranties, 
proprietary  code,  or  special  considerations. 

Under  no  circumstances  is  a  contractor  permitted  to  make  any  use  of 
agency  computer  equipment  or  supplies  for  purposes  other  than 
performance  on  this  contract. 

The  following  items  of  government  furnished  equipment  or  software 
have  the  following  licensing  or  use  restrictions:      (provide  list) 

The  special  needs  of  personal  computers  should  be  addressed.  There  are  many  PC 
security  options  such  as  PC  security  hardware  and  software,  locks,  removable  hard 
drives,  and  anti-virus  software.  Consider  if  these  are  needed  when  PCs  are  acquired 
or  if  contractors  will  be  using  PCs.  Remember  that  a  PC  used  as  a  terminal  is  still 
a  computer. 

The  contractor  shall  not  allow  employees  to  use  files  for  logging 
onto  systems  that  contain  the  employee's  passwords. 

Pre-logon  warning  messages  can  deter  unauthorized  use,  increase  computer  security 
awareness,  and  provide  a  legal  basis  for  prosecuting  unauthorized  access.  Consider 
having  an  installation,  support,  or  integration  contractor  configure  multi-user  systems 
with  a  warning  message.  Warning  messages  can  also  be  used  on  contractor  systems 
processing  federal  information. 

The  system (s)   shall  be  delivered/installed  with  the  following 
message  appearing  before  logon: 

(or) 

Contractor  multi-user  systems  used  to  process  data  under  this 
contract  shall  use  the  following  pre-logon  warning  message: 
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WARNING  WARNING  WARNING 

******************************************************** 

THIS  COMPUTER  IS  OPERATED  BY/FOR  THE  U.S.   GOVERNMENT.  UNAUTHORIZED 
ACCESS  TO  AND/OR  USE  OF  THIS  COMPUTER  SYSTEM  IS  A  VIOLATION  OF  LAW 
AND  PUNISHABLE  UNDER  THE  PROVISIONS  OF  18  USC  1029,    18  USC  1030,  AND 
OTHER  APPLICABLE  STATUTES. 

****************************************1r***.)r.k***i.ic±i.icieic*icirir1.*i. 

WARNING  WARNING  WARNING 


Having  the  contractor  provide  contingency,  continuity  of  operations,  and  disaster 
recovery  plans  for  government  systems  or  for  their  own  systems  that  process 
government  data  is  another  important  issue.  The  following  addresses  continuity  of 
operations  planning  for  a  mission-essential  network,  but  can  be  tailored  for  other 
types  of  systems.  To  use  this  clause,  the  offerors  must  have  sufficient  information 
to  be  able  to  postulate  the  types  of  emergencies  that  could  occur.  It  may  be 
necessary  to  provide  additional  detailed  specifications  to  give  offerors  and  evaluators 
enough  information  to  prepare/review  cost  estimates  and  to  make  objective 
evaluations. 

Add  to  Section  L: 

As  part  of  the  proposal,   the  offeror  shall  submit  a  preliminary 
continuity  of  operations  plan  to  address  the  planned  reaction  to 
threatened  or  actual  emergencies.     Provisions  for  testing  the  plan, 
at  the  option  of  the  agency,  must  be  included  in  the  proposal. 

The  offeror  shall  describe  how  proposed  architecture,  technical 
capabilities  and  organization  will  protect  the  system  during 
emergency  situations.     The  plan  should  state  what  priority  the 
agency  will  have  in  terms  of  services,   replacement  hardware,  etc. 
Examples  of  how  these  resources  will  be  brought  to  bear  during  an 
emergency  are  required. 

The  offeror  shall  describe  external  emergency  management  interface 
arrangements  that  will  be  used  with  subcontractors  if  necessary. 

The  agency  is  concerned  that  service  may  be  degraded  in  a  network 
environment  in  which  switching  systems  and  transmission  channel  are 
shared  with  others.     If  the  offeror  proposes  such  a  shared 
environment,   the  offeror  must  address  the  following  issues: 

protection  of  critical  agency  users  from  access  blocking; 
protection  of  network  access  ports  from  saturation  caused  by 
other  traffic  that  may  be  using  the  network  access  ports;  and 
provision  of  low  delay,   low  blocking  access  to  all  necessary 
intercity  routes  and  access  facilities  for  critical  users 
during  periods  of  overload. 
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Add  to  Section  C: 

After  contract  award,   the  contractor  shall  deliver  a  draft 
continuity  of  operations  plan  for  the  system  being  acquired  for 
agency  approval  within  ninety  days  of  receiving  the  agency  approval 
and/or  guidance  on  the  preliminary  plan.     The  final  continuity  of 
operations  plan  shall  be  delivered  ninety  days  after  receiving 
agency  approval  and/or  guidance  on  the  draft  plan.     The  plan  shall 
be  periodically  reviewed  and  updated  annually  by  the  Contractor  to 
ensure  the  accuracy  and  timeliness  of  the  contents.  Recommended 
updates  and  revision  based  on  this  review  shall  be  submitted  to  the 

agency  for  approval    working  days  prior  to  incorporation  in  the 

plan . 

Summary : 

Preliminary  plan  submitted  with  proposal; 

Draft  plan  submitted    working  days  after  agency 

comment  on  preliminary  plan;  and 

Final  plan  submitted    working  days  after  agency 

comment  on  draft  plan. 

The  continuity  of  operations  plan  shall  detail  the  taking  of 
appropriate  and  timely  action  to  protect  system  assets  from  damage 
or  misappropriation  in  the  event  of  the  threat  of  a  disaster  or 
emergency.     The  emphasis  shall  be  on  avoiding  or  mitigating  the 
damage  caused  by  such  things  as  fire,    flood,   or  terrorist  activity 
(modify  to  include  threats  to  the  system) .     The  plan  shall,  at  a 
minimum: 

Include  a  risk  assessment; 

Identify  essential  functions  or  critical  processes,  components, 
and  the  relationship  of  critical  workload  to  variables  such  as 
time  to  recovery; 

Identify  activities  that  can  be  temporarily  suspended; 
Identify  alternate  procedures;  and 

Identity  action (s)   to  be  taken  to  mitigate  threats. 

The  continuity  of  operations  plan  shall  detail  the  taking  of 
appropriate  and  timely  action  to  return  assets  to  use  after  damage, 
destruction,   alteration  or  misappropriation.     The  system  recovery 
portion  of  the  plan  shall  include  at  a  minimum: 

The  basic  strategy  for  recovery; 

Specifications  for  restoration  procedures  by  component  and 
subsystem  priority;  and 

Specific  responsibilities  for  emergency  response. 

The  continuity  of  operations  plan  shall  state  how  the  plan  shall  be 
tested  and  how  often  the  tests  shall  be  done.     Annual  testing  is 
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required  as  a  minimum  and  some  tests  should  be  done  without  advance 
notice . 

As  part  of  continuity  of  operations/contingency  planning,  consider  how  long  the 
system  can  be  down. 

In  the  event  the  system  or  any  component  is  rendered  permanently 

inoperative,   the  contractor  shall  deliver  a  replacement  within   

working  days  from  the  date  of  request. 

In  the  event  the  system  or  any  component  is  unavailable  for  use  due 
to  maintenance  or  repair  or  other  reasons  for  a  period  of  more  than 

  hours   (or  days) ,   or  in  the  event  that  it  is  reasonably 

anticipated  that  maintenance  will  exceed    hours,   the  contractor 

shall  make  a  loaner  or  replacement  available  within    hours  (or 

days) . 
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C.  Control  of  Information/Data 


Contractors  may  have  to  work  with  information  or  data  that  the  agency  has 
designated  as  nondisclosable.  Clauses  should  be  used  to  prevent  the  contractor  from 
disclosing  the  information  during  the  course  of  the  contract  and  after  it  has 
terminated.  It  is  important  to  work  with  the  contracting  officer  to  ensure  that 
nondisclosure  is  adequately  addressed  for  both  situations. 

Any   (list  type  of  or  all)    information  made  available  in  any  format 
shall  be  used  only  for  the  purpose  of  carrying  out  the  provisions  of 
this  contract.     Information  contained  in  such  material  shall  not  be 
divulged  or  made  known  in  any  manner  to  any  person  except  as  may  be 
necessary  in  the  performance  of  this  contract.     Disclosure  to  anyone 
other  than  an  authorized  officer  or  employee  of  the  contractor  shall 
require  written  approval  of  the  contracting  officer   (or  contracting 
officer's  technical  representat ive/COTR) . 

Any   (list  type  of)    information  shall  be  accounted  for  upon  receipt 
and  properly  stored  before,   during  and  after  processing.  In 
addition,   all  related  output  shall  be  given  the  same  level  of 
protection  as  required  for  the  source  material. 

If  it  is  necessary  to  disclose   (type  of)   information  to  perform 
under  the  contract,   the  contractor  shall  request  written 
authorization  from  the  contracting  officer   (or  COTR)   to  make  such 
necessary  disclosure. 

(1)  Except  as  provided  elsewhere  in  this  contract,  the 
contractor  shall  not  disclose   (type  of  information)   except  to 
the  individual  specified  in  this  contract. 

(2)  Only  those  disclosures  specifically  authorized  in  writing 
by  the  contracting  officer   (or  COTR)  may  be  made,   and  only  when 
it  is  clearly  shown  by  the  contractor  that  such  disclosures  are 
essential  to  successfully  perform  under  this  contract. 

(3)  Should  the  contractor  or  one  of  his/her  employees  make  any 
unauthorized  disclosure ( s )   of  confidential  information,  the 
terms  of  the  Default  clause   (FAR  52.249-8),   incorporated  herein 
by  reference,  may  be  invoked,  and  the  contractor  will  be 
considered  to  be  in  breach  of  this  contract. 

If  nondisclosable  information  is  released  to  prospective  offerors  in  order  for  them  to 
prepare  proposals,  the  following  clause  can  be  used  during  the  release  of 
information. 
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I  hereby  certify  that  I  will  not  disclose  (type  of  information) 
unless  authorized  in  writing  by  the  contracting  officer  (or  COTR) . 
I  agree  that,  whether  or  not  a  contract  is  awarded  to  me,   I  will 
keep  all  information  confidential. 

The  following  item  is  to  prevent  nondisclosable  information  from  leaving  the 
agency's  control  through  such  means  as  being  on  a  disk  drive  sent  out  for 
maintenance. 

The  contractor  shall  ensure  that   (list  type  of)   information  shall 
not  be  released  outside  the  control  of  the  agency   (or  specific 
agency  office) ,   including  release  for  maintenance  or  replacement 
purposes,  without  the  written  consent  of  the  contracting  officer  or 
COTR . 
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D.   Security  Documentation 


Security  documentation  provides  instruction  about  the  use  of  the  system  security, 
assurance  that  the  security  requirement  has  been  understood,  and  supports  a 
demonstration  of  meeting  the  requirement.  The  items  below  are  divided  into 
proposal  and  deliverable  documentation.   In  general,  documentation  that  shows  that  a 
requirement  has  been  understood  will  be  received  as  part  of  the  proposal  and  will  be 
used  to  evaluate  the  offeror.  Instructional  documentation  will,  in  general,  be 
received  as  a  deliverable  after  contract  award.  Documentation,  such  as  test 
documentation,  that  demonstrates  that  the  contractor  has  successfully  met  the  security 
requirement  will  normally  be  received  as  a  deliverable  after  contract  award. 

Depending  on  the  nature  of  what  is  being  acquired,  these  types  of  documentation 
can  be  mixed.  For  instance,  an  approach,  abstract,  or  outline  of  a  Security  Features 
User's  Guide  can  be  included  in  the  proposal  with  the  final  version  as  a  deliverable. 
In  the  proposal  phase,  the  document  would  be  used  to  evaluate  the  offeror's 
understanding  of  the  security  requirement  and  their  ability  to  meet  the  requirement. 
As  a  deliverable,  this  would  become  instructional  documentation.  Be  sure 
documentation  requested  with  the  proposal  is  used  for  evaluation  of  the  offer  and 
does  not  constitute  having  the  offeror  prepare  deliverables  before  award. 

Depending  on  what  is  being  acquired,  be  sure  to  get  system  level  documentation, 
not  just  component  documentation.  For  any  type  of  documentation  at  the  system 
level,  the  contractor  should  describe  the  system  security  requirement  and  how  it  has 
been  implemented.  The  operating  system  documentation  plus  the  security  system 
documentation  plus  application  documentation  does  not  equal  system  documentation. 
System  security  documentation  includes  interrelationships  among  applications  and 
with  the  operating  system  and  utilities  in  its  environment.  Component 
documentation  will  generally  be  off-the-shelf,  whereas  system  documentation  will 
generally  be  developed  by  the  contractor. 

It  may  be  necessary  to  provide  additional  detailed  specifications,  including  content 
and  delivery  schedule,  to  give  offerors  and  evaluators  enough  information  to 
prepare/review  cost  estimates  and  to  make  objective  evaluations. 

PROPOSAL  DOCUMENTATION 

Offeror's  strategy  for  security.  This  should  be  commensurate  with  the  size  and 
complexity  of  the  system.   All  systems  acquisitions  should  request  some  form  of 
offeror  security  strategy.   In  this  strategy,  the  offeror  should  state  how  the  product 
or  service  will  meet  the  security  needs  of  the  government.   Offerors  of  off-the-shelf 
products  should  match  the  features  of  the  packages  to  government  specifications  and 
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address  assurance.  For  complex  system  development  efforts,  this  could  include  a 
plan  for  incorporating  and  assuring  security  throughout  the  development.  An 
example  of  a  clause  requesting  such  a  plan  follows. 

The  offeror  shall  provide  a  plan  that  describes  its  automated 
information  security  program.     The  plan  shall  address  the  security 
measures  and  program  safeguards  which  will  be  provided  to  ensure 
that  all  information  systems  and  resources  acquired  and  utilized  in 
the  performance  of  the  contract  by  contractor  and  subcontractor 
personnel : 

(1)  Operate  effectively  and  accurately; 

(2)  Are  protected  from  unauthorized  alteration,  disclosure, 
or  misuse  of  information    processed,   stored,  or 
transmitted; 

(3)  Can  maintain  the  continuity  of  automated  information 
support  for  agency  missions,  programs,   and  function; 

(4)  Incorporate  management,   general,   and  application  controls 
sufficient  to  provide  cost-effective  assurance  of  the 
system's  integrity  and  accuracy,  and 

(5)  Have  appropriate  technical,  personnel,  administrative, 
environmental,   and  access  safeguards. 

This  plan  will  be  included  in  any  resulting  contract  for  contractor 
compliance . 

Offeror's  internal  security  policy  and  plan.  Procurements  that  include  contract 
services  can  ask  for  this  type  of  assurance  document.  Depending  on  the  scope  of 
the  acquisition,  this  may  include  copies  of  the  offeror's  applicable  computer  security, 
personnel  security,  and  physical  security  policies. 

DELIVERABLE  DOCUMENTATION 

Security  Features  User's  Guide.   A  description  of  the  protection  mechanisms 
provided  by  the  system,  guidelines  on  their  use,  and  how  they  interact  with  one 
another.   If  a  system  is  being  procured,  be  sure  to  get  system  level  documentation, 
as  well  as  product  documentation. 

System  Administrator/Facility  Manual.  A  manual  addressed  to  the  system 
administrator  that  presents  cautions  about  functions  and  privileges  that  should  be 
controlled  when  running  the  system  or  facility  in  a  secure  manner.  The  procedures 
for  examining  and  maintaining  security  features  requested  (such  as  audit  record 
structures)  should  also  be  requested.  The  manual  should  describe  the  operator  and 
administrator  functions  related  to  security,  to  include  changing  the  security 
characteristics  of  a  user.   It  should  provide  guidelines  on  the  consistent  and  effective 
use  of  the  protection  features  of  the  system,  how  they  interact,  warning,  and 
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privileges  that  need  to  be  controlled  in  order  to  operate  the  system  or  facility  in  a 
secure  manner.  If  a  system  is  being  procured,  be  sure  to  get  system  level 
documentation,  as  well  as  product  documentation. 

Test  documentation.  A  report  that  describes  the  test  plan,  test  procedures  that 
show  how  the  security  mechanisms  were  tested  and  results  of  the  security 
mechanisms'  functional  testing. 

Design  documentation.  A  report  that  provides  a  description  of  the  manufacturer's 
or  developer's  philosophy  of  protection  and  an  explanation  of  how  this  philosophy  is 
translated  in  the  system.  This  report  can  be  the  post-contract  award  counterpart  of 
the  offeror's  strategy  for  security;  it  describes  how  the  strategy  was  implemented. 
This  can  also  include  an  informal  or  formal  description  of  a  security  policy  model 
and  an  explanation  of  how  the  system  enforces  the  security  policy.  For  systems 
requiring  very  high  security  assurance,  formal  description  languages  and 
mathematical  modeling  may  also  be  included. 

Additional  information  on  documentation  for  automated  systems  is  available  from  the 
following  FIPS  PUBs: 

FIPS  38       Guidelines  for  Documentation  of  Computer  Programs  and 

Automated  Data  Systems 
FIPS  64       Guidelines  for  Documentation  of  Computer  Programs  and 

Automated  Systems  for  the  Initiation  Phase 
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E.  Legal  Issues 


The  contracting  officer  and  the  legal  department  need  to  be  consulted  about  legal 
issues.   This  section  addresses  some  issues  that  the  procurement  initiator  may  want 
to  discuss  with  agency  procurement  and  legal  staff. 

It  is  possible  for  computer  products  to  cause  security  violations  even  if  the  products 
are  functioning  correctly.  These  violations  could  be  caused  by  the  product 
containing  malicious  code  (i.e.,  virus  or  trojan  horse),  making  operating  system  calls 
that  bypass  system  controls,  or  containing  undocumented  backdoors  that  bypass 
security.   Many  manufacturers  include  backdoors  so  they  can  assist  customers. 

The  FAR  contains  general  clauses  which  define  the  respective  responsibilities  and 
allocate  risks  among  the  parties  to  a  government  contract.   However,  additional 
clauses  may  be  needed  to  fully  address  specific  computer  security  requirements. 
Such  clauses,  for  example,  may  address  guarantees,  warranties,  or  liquidated 
damages.  The  specific  wording  of  such  clauses  may  vary  from  one  solicitation  to 
another  because  they  are  a  function  of  the  particular  need  for  data  integrity, 
confidentiality  or  availability  and  the  nature  of  the  system  being  protected. 

Agencies  may  wish  to  consider  the  use  of  warranties,  liquidated  damages,  and  other 
clauses  establishing  the  contractor's  computer  security-related  responsibilities  in 
contracts.   Such  clauses,  when  properly  crafted,  will  provide  incentive  to  the 
contractor  to  assure  that  its  products  and  services  meet  the  security  requirements  of 
the  contract.   Such  clauses,  when  poorly  drafted  or  overly  broad,  can  unnecessarily 
increase  contract  costs,  limit  competition,  complicate  contract  administration  and 
increase  litigation  risk.  These  clauses  must  be  prepared  in  conjunction  with  existing 
FAR  clauses. 

Warranties  provide  a  means  to  require  the  contractor  to  fix  products  after  they  have 
been  accepted.   A  warranty  is  an  agreement  by  the  contractor  that  it  will  be  liable 
for  meeting  the  contract  specifications  for  a  stated  period  of  time  after  acceptance. 
(See  FAR  46.7  and  52.246-17  through  -20.) 

Liquidated  damages  provide  a  means  for  the  contractor  to  compensate  the 
government  for  losses  that  result  from  contract  delays  or  other  problems.  The 
purpose  of  liquidated  damages  clauses  and  other  clauses  fixing  contractor's 
performance  responsibilities  in  the  computer  security  area  is  to  provide  incentive  for 
the  contractor  to  make  sure  that  the  product  only  does  what  it  is  intended  to  do  and 
nothing  more.   For  example,  the  product  should  be  free  from  malicious  code.  This 
is  done  by  having  the  contractor  pay  for  damages  that  result  from  poor  security. 
Since  the  goal  is  to  acquire  secure  systems,  the  extent  of  the  liquidated  damages 
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clause  (or  other  such  clause)  should  be  commensurate  with  the  anticipated  risks  and 
damage  to  the  government.  A  specific  maximum  dollar  value  can  be  placed  on  the 
damages  or  other  means  can  be  used  to  limit  the  contractor's  liability. 

Note:  These  are  not  penalties.  If  a  security  violation  occurs,  but  does  not  result  in 
any  loss,  the  contractor  is  not  responsible  for  any  liability  or  liquidated  damage. 

The  following  are  examples  of  integrity  statements  which  may  be  modified  to  form 
a  warranty,  guarantee,  or  liquidated  damage  clause.  The  examples  are  not  intended 
to  be  used  together  and  should  be  modified  for  the  operating  environment.  There 
are  no  examples  of  customized  enforcement  clauses  (the  specific  warranty,  guarantee, 
or  liquidated  damage)  because  they  must  be  developed  with  the  contracting  officer 
and  legal  counsel.   FAR  52.246-17  through  -20  contain  FAR  standard  warranties. 


1.       The  subject  product  performs  in  accordance  with  all 

specifications,   certifications,  and  representations  reflected 
in  the  documentation  provided  in  Addendum  1  except  as  reflected 
below: 


2.       The  installation  instructions  provided  with  the  subject  product 
if  properly  followed  shall  result  in  the  creation  and 
modification  of  only  those  objects  listed  below: 


3.       The  subject  product   (hardware  or  software)   shall  not  interact 
with  any  other  component    (hardware,   software,   or  firmware)  of 
the  system  onto  which  it  is  being  installed  to  perform  any 
function  not  described  in  the  documentation  listed  below: 


4.  The  instructions  provided  for  removing  the  subject  product  from 
any  system  onto  which  it  has  been  properly  installed,  shall,  if 
properly  followed,  release  back  to  the  system  every  object  used 
to  store  the  subject  product  on  the  system. 


52 


5.       Other  than  the  exceptions  listed  below,   the  subject  product 

contains  no  undocumented  functions  and  no  undocumented  methods 
for  gaining  access  to  this  software  or  to  the  computer  system 
on  which  it  is  installed.     This  includes,   but  is  not  limited 
to,  master  access  keys,  back  doors,   or  trapdoors. 


6.       The  subject  product  does  not  interfere  or  bypass  the  system 

security  software   [insert  name(s)   of  security  software].  The 
program  code  only  performs  request  validation  checking  and 
enforces  the  action  that  the  system  security  software  indicates 
should  be  taken.     This  processing  is  done  for  all  users.  Any 
exceptions  are  listed  below. 


Government  patents  and  ownership  of  developed  software  and  systems  are  another 
important  considerations  that  should  be  discussed  with  the  contracting  officer  and 
legal  staff. 
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F.   Administration,  End  of  Task,  Closeout 


One  issue  for  contract  closeout  is  the  return  or  destruction  of  government 
data/information.   Since  information  can  be  easily  copied,  the  return  of  originals 
does  not  fully  address  the  destruction  of  the  information.  This  issue  only  needs  to 
be  addressed  when  the  government  is  having  information  processed  on  a  contractor 
facility  or  computer.   Be  sure  that  official  agency  records  or  information  is  not 
destroyed  before  a  copy  of  the  information  has  been  received  by  the  agency  (if 
needed). 

The  contractor  certifies  that  the  data  processed  during  the 
performance  of  this  contract  shall  be  purged  from  all  data  storage 
components  of  its  computer  facility,   and  no  output  will  be  retained 
by  the  contractor  after  such  time  as  the  contract  is  completed.  If 
immediate  purging  of  all  data  storage  components  is  not  possible, 
the  contractor  certifies  that  any  agency  data  remaining  in  any 
storage  component  will  be  safeguarded  to  prevent  unauthorized 
disclosures.      (Insert  schedule.) 

Government  furnished  equipment  (GFE)  including  hardware  and  software  should  be 
returned  in  accordance  with  normal  procedures.   Special  computer  security 
considerations  include  the  return  of  the  GFE  in  usable  condition.   This  is  especially 
important  if  a  system  is  going  to  continue  operation  under  the  government's  or 
another  contractor's  control.  The  computer  security  can  be  transferred  by  having 
passwords  reset  by  the  government  or  by  having  the  contractor  turn  in  the 
passwords.   The  delineation  of  security  responsibilities  during  transition  should  be 
addressed.   No  specific  language  is  provided  because  of  the  diversity  and 
individuality  of  systems. 

Returned  software  shall  be  certified  to  be  in  its  original  form. 

Another  item  to  be  considered  is  computer  accounts  on  government-owned  systems. 
Accounts  no  longer  needed  by  the  contractor  should  be  terminated  to  protect 
government  resources,  i.e.,  computer  time,  and  to  prevent  malicious  activity  by 
unauthorized  users. 

When  an  employee  no  longer  requires  access  to  the  system  (if  the 
employee  leaves  the  company  or  the  contract),   the  contractor  shall 

notify  the  COTR  within    working  days.     At  contract 

completion  or  termination,   the  contractor  shall  provide  a  status 
list  of  all  users  and  note  if  any  users  still  require  access  to  the 
system  to  perform  work  under  another  contract.     Any  group  accounts 
or  other  means  of  gaining  access  to  the  system  shall  be  listed  also. 
This  includes  maintenance  accounts  and  security  bypasses. 
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If  a  user  is  fired  or  leaves  the  contract  or  company  under  adverse 
conditions,    the  contractor  shall  notify  the  COTR  before  the  employee 
is  removed.     If  the  removal  is  unplanned,   the  contractor  shall 
notify  the  COTR  immediately  after  dismissing  the  employee.  This 
will  allow  the  government  to  terminate  his/her  access. 

When  an  employee  leaves  a  contract  and  at  contract  closeout,  it  is  important  to 
dispose  of  computer  files  as  well  as  accounts.   Often  only  the  person  who 
created/used  the  files  has  sufficient  knowledge  to  dispose  of  them.  If  the  contractor 
will  be  handling  official  agency  records,  be  sure  disposition  is  made  in  accordance 
with  agency  records  management  instructions. 

When  an  employee  leaves  the  contract,   the  contractor  project  manager 
shall  ensure  that  all  files  are  disposed  of  by  transfer  to  another 
user,   archive,   destruction,   etc.     The  contractor  project  manager 
shall  report    (or  certify)   disposition  in   (time  frame  such  as  in  a 
monthly  report  or  within    weeks  of  the  employee  leaving.) 

For  complex  contracts  that  include  the  development,  implementation,  or  operation  of 
a  computer  facility  or  application,  a  security  working  group  can  be  used  effectively 
to  help  maintain  computer  security.  The  group  can  be  composed  of  a  combination 
of  government  and  contractor  personnel.   Depending  on  the  operational  environment, 
the  group  can  be  used  for: 

information  exchange; 
configuration  management; 
certification  and  accreditation  issues; 
analyzing  security  requirements; 
identifying  new  threats  and  vulnerabilities; 
identifying  changes  to  the  system  that  impact  security; 
recommending  solutions  to  security  problems  as  they  occur;  and 
making  recommendations  based  on  tradeoffs  between  security  and  other 
functional  requirements. 

The  following  examples  define  a  security  working  group  used  to  support  an 
operational  system. 

The  contractor  shall  provide    (number  and  type  of)   personnel  for  a 
security  control /review  group.     This  group  will  address  security 
problems,  help  provide  for  the  maintenance  of  accreditation  or 
certification  under  the  control  of   (government  person  responsible 
for  computer  security  of  system) ,   report  security  problems,   and  make 
security  recommendations. 

The  contractor  can  be  responsible  for  the  administration  and  support  of  the  group. 
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The  contractor  shall  schedule  meetings  monthly   (or  other  time 
frame),   arrange  for   (or  provide)   a  room,   and  take  minutes.  The 
minutes  will  be  submitted  to  the  COTR/GTR  within  one  calendar  week 
after  the  meeting.     The  meetings  shall  commence  one  month   (or  other 
time  frame)   after  contract  award  and  continue  throughout  the  period 
of  performance   (or  other  ending  time) . 


56 


G.   Computer  Security  Training  and  Awareness 


An  important  goal  of  the  Computer  Security  Act  is  to  have  all  personnel  involved  in 
the  management,  use,  and  operation  of  federal  systems  trained  in  computer  security 
awareness  and  accepted  computer  security  practices.   OMB  Circular  A- 130, 
Appendix  HI,  specifically  requires  that  contractor  personnel  involved  in  the 
management,  operation,  programming,  maintenance,  or  use  of  federal  systems  be 
aware  of  their  security  responsibilities  and  how  to  fulfill  them. 

The  following  can  be  used  in  the  cases  where  the  agency  determines  that  NIST 
Special  Publication  500-172  "Computer  Security  Training  Guidelines"  adequately 
addresses  the  security  training  requirement  for  the  contractor.   This  can  be  tailored 
to  include  specific  additional  skills,  training  levels,  or  audience  categories  depending 
on  the  requirements  of  the  agency.   A  time  frame  should  be  specified  for  when  the 
contractor  personnel  must  have  received  the  training.   The  development  of  training 
certifications  should  be  discussed  with  the  contracting  officer. 

The  contractor  shall,   at  a  minimum,   certify  that  all  contractor 
personnel  involved  in  the  management,  use,   and  operation  of  (name 
of)    system (s)  who  perform  work  under  the  subject  effort  shall  have 
received  training  appropriate  to  their  assignment  as  defined  in  NIST 
Special  Publication  500-172   "Computer  Security  Training  Guidelines." 

Each  individual    (or  category  of  contractor  personnel)   proposed  for 
the  effort  shall  be  identified  with  appropriate  audience 
category(s),    as  defined  in  NIST  Special  Publication  500-172,  pages 
3-4.       The  contractor  shall  certify  each  as  having  received  computer 
security  training  appropriate  to  their  categories,   as  denoted  in  the 
training  matrix  on  page  6  of  500-172  and  described  in  pages  8-27. 

Additional /refresher  training  shall  be  performed    (time 

period) .     Certification  of  this  training  shall  be  provided  to  the 

contracting  officer  no  later  than    calendar  days  after  the 

training  has  occurred. 

The  following  are  examples  of  tailoring  the  training  specification. 

In  addition,  all  contractor  personnel  involved  in  the  administration 
of  the  access  control  package  shall  have  received  training  on  the 

package  equivalent  to    hours  of  classroom  instruction  or   

hours  of  job  experience  using  the  package. 

The  contractor  system  security  personnel  shall  have  received 
training  in  the  operations  of  the  system  that  includes  a  systemic 
overview,   the  security  features,   known  vulnerabilities  and  threats, 
and  security  evaluation  methodologies. 


57 


The  following  can  be  used  when  the  acquisition  agency  has  specific  training 
minimums  that  are  available  to  the  prospective  offerors.   The  second  paragraph  may 
be  added  as  an  Instruction  to  Offerors. 

The  contractor  shall,   at  a  minimum,   certify  that  any  personnel  who 
perform  work  under  the  subject  effort  shall  have  received  security 
awareness  and  skills  training  that  is  equivalent  to  that  received  by 
government  personnel  at    (fill  in  location). 

It  is  the  responsibility  of  the  prospective  offeror  to  obtain  the 
agency  guidelines  for  this  training  prior  to  the  submission  of  a 
proposal  under  this  solicitation  at    (fill  in  address  and  point  of 
contact) .      (Alternate:     The  agency  guidelines  can  be  included  as  an 
attachment  to  the  RFP . ) 
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H.   Personnel  Security 


Requiring  vetting,  or  personnel  screening,  of  contractor  or  subcontractor  employees 
as  a  condition  for  access  to  government  resources  is  a  recommended  safeguard.  The 
type  of  access  can  be  physical  or  computer  systems  access.  The  level  of  vetting 
should  be  based  on  an  assessment  of  risk,  cost,  benefit,  and  feasibility.  Vetting 
includes  a  range  of  implementations  from  minimal  checks  to  full  background 
investigations.  The  extent  of  screening  is  dependent  on  the  sensitivity  of  the  system 
or  data  and  the  implementation  of  other  administrative,  technical,  and  physical 
safeguards. 

Be  sure  to  include  in  the  contract: 

what  types  of  investigations  are  required  for  what  types  of  access; 
who  will  review  the  investigation  to  determine  access  privileges; 
who  is  paying  for  the  investigations; 

whether  the  investigations  must  be  reviewed  before  access  is  granted; 
when  names  and  supporting  information  must  be  submitted; 
what  other  types  of  clearances  (from  other  government  agencies)  can  be 
substituted;  and 

how  investigations  or  results  will  be  reported  on  or  certified  to  the  contracting 
officer. 

Different  vetting  could  also  be  required  for  different  types  or  levels  of  access. 
There  are  many  kinds  of  investigations.   OPM  Federal  Personnel  Manual  Chapter 
736  Subchapter  3  describes  some  investigations  as  they  pertain  to  government 
investigations.   The  list  below  includes  those  and  other  forms  of  investigations: 

Review  of  the  employment  forms  completed  by  the  individual; 
Personal  reference  check; 
Credit  check; 

Verification  of  employment  for  the  last  2  years  prior  to  current  employment; 

Verification  of  education  (high  school  or  beyond)  within  the  last  5  years  that 

resulted  in  the  awarding  of  a  degree; 

Local  police  check  in  present  county  and  state; 

National  criminal  check  by  private  agency; 

National  Agency  Check  (NAC); 

National  Agency  Check  and  Inquiries  (NACI); 

Minimum  Background  Investigation  (MBI); 

Limited  Background  Investigation  (LBI); 

Background  Investigation  (BI);  and 


59 


Special  Background  Investigation  (SBI)  that  includes  verification  of  all 
previous  places  of  employment  and  residence  for  a  several  year  period  (e.g., 
15  years). 

Access  to  the  government's  resources  is  a  privilege  and  should  be  revoked  if  an 
individual  becomes  a  threat  to  the  system. 

The  government  may  remove  access  privileges  for  contractor  personnel 
for  unauthorized,  negligent,  or  willful  actions.  These  may  include, 
but  are  not  limited  to: 

exploration  of  the  system; 
introduction  of  malicious  software; 

unauthorized  modification  or  disclosure  of  the  system  or  data; 
and 

failure  to  logoff. 

There  are  other  types  of  personnel  security  methods  besides  investigations  such  as 
employee  statements  regarding  conflict  of  interest.  Conflict  of  interest  can  include 
procurement  integrity  certifications,  financial  disclosure,  or  reports  on  outside 
activity.   Be  sure  to  specify  what  is  required,  when  the  form(s)  must  be  completed 
and  what  access  decision(s)  are  based  on  the  form. 

If  the  agency  has  a  computer  systems  user  agreement  that  states  user  computer 
security  responsibilities  (such  as  safeguarding  passwords),  it  is  appropriate  to  require 
contractor  personnel  sign  the  agreement  before  computer  systems  access  is  granted. 
The  following  clause  can  be  modified  to  be  more  stringent  (such  as  agency  receipt 
of  agreement  before  access  in  granted). 

The  contractor  shall  insure  that  all  contractor  personnel  sign  the 
user  agreement    (sample  attached  in  Section  J  of  RFP)   prior  to  having 
access  to  agency  systems. 

Care  must  be  taken  when  addressing  the  area  of  contractor  personnel.  The 
government  cannot  engage  in  personal  services  contracts  unless  specifically 
authorized  by  statute.   Personal  services  contracts  are  those  where  the  government 
has  an  employer-employee  relationship  with  contractor  staff.   See  Part  37  of  the 
FAR  "Service  Contracting."   Requiring  contractor  personnel  to  be  vetted  as  a 
condition  for  employment  under  the  contract  suggests  an  employer-employee 
relationship.   However,  requiring  vetting  of  contractors  as  a  condition  for  access  to 
government  resources  is  different.   It  does  not  imply  an  employer-employee 
relationship  since  the  government  has  a  responsibility  to  retain  control  of  its 
resources. 
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While  the  distinction  above  may  seem  minor,  it  can  be  essential  during  a  contract. 
It  is  important  that  the  distinction  is  understood  to  avoid  personal  services  contracts 
while  protecting  government  resources. 
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I.   Physical  Security 


The  following  types  of  clauses  can  be  used  for  contracts  where  work  will  be 
performed  at  the  contractor  location. 

Physical  security  for  computer  systems  helps  prevent  theft,  tampering,  and 
destruction. 

The  contractor  shall  provide  physical  security  for   (list  components 
or  systems)   other  than  those  in  agency  controlled  space  and  for 
information  being  transmitted  across   (list  networks).  Physical 
security  measures  to  be  implemented  include  protecting  the: 

site   (e.g.,   access  to  computer  room); 

hardware   (e.g.,   communications  processors,  modems);  and 
software  and  data. 

The  contractor  shall  identify   (name  of  system  or  components) 
equipment  that  will  be  in  nonagency  controlled  areas.     Methods  for 
physically  protecting  these  systems  shall  be  provided  by  the 
Contractor.     The  protection  shall  be  against  damage,  unauthorized 
access,   alteration,  modification  and  destruction,  whether  by  act  of 
nature,   accident,   or  intrusion. 

Computer  security  should  be  considered  as  an  issue  for  preaward  site  surveys.  In 
general,  computer  security  should  be  integrated  into  existing  agency  clauses  for 
preaward  site  surveys  instead  of  using  this  clause. 

When  it  is  determined  that  a  preaward  site  survey  is  necessary  in 
order  to  verify  that  the  security  of  a  facility  is  adequate,  the 
contracting  officer  shall  notify  the  offeror  that  such  a  survey  will 
be  necessary  and  coordinate  with  the  offeror  as  necessary.  No 
contract  for  services  or  supplies  will  be  awarded  until  the  survey 
is  completed.     The  recommendations  of  the   (office  performing 
survey),   as  appropriate,  will  be  a  significant  factor  in  the 
determination  of  responsibility. 
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J.   Computer  Security  Features  in  Systems 


Computer  security  features  in  systems  refer  to  specific  functions  to  be  incorporated 
or  bought  with  applications,  operating  systems,  and  hardware.   How  security  features 
are  incorporated  is  dependent  on  the  function  and  environment  of  the  system. 

For  many  systems,  a  combination  of  features  will  be  used,  some  of  which  are 
incorporated  in  the  operating  system  and  some  in  the  application.   For  example, 
additional  access  controls  at  a  finer  level  of  granularity  (record  or  field)  and  edit 
checks  are  commonly  incorporated  at  the  application  level,  while  file  access  may 
still  be  performed  by  the  operating  system.   Many  other  security  architectures  are 
possible.   Whatever  security  architecture  is  selected,  it  is  imperative  that  the  security 
features  work  together  in  the  system  environment  and  that  the  documentation  and 
testing  address  the  coordinated  approach. 

This  section  addresses  several  controls  that  are  normally  associated  with  operating 
systems  but  can  be  provided  by  an  application.   Additional  application-oriented 
controls  are  described  in  FIPS  PUB  73  Guidelines  for  Security  of  Computer 
Applications. 

The  features  described  in  this  section  are  a  combination  of  basic  security  controls 
and  some  advanced  controls.   The  controls  are  described  in  functional  specifications. 
Individual  tailoring  to  specific  environments  will  probably  be  required.   If  the 
intention  of  the  procurement  is  to  acquire  off-the-shelf  products,  market  surveys 
should  be  performed  to  determine  what  features  are  currently  commercially  available. 
Modifying  security  features  of  off-the-shelf  products  can  be  expensive.  (Market 
surveys  should  be  performed  in  accordance  with  agency  policy.) 

This  section,  like  the  other  sections  in  this  guidelines,  is  a  list  of  possible  features, 
procedures,  and  assurances.   Additional  information  on  the  uses  of  these  features  can 
be  obtained  from  agency  security  officials  and  NIST  and  other  publications.  NIST 
Publication  List  91,  which  is  periodically  updated,  catalogues  the  NIST  computer 
security  publications.   Technical  terms  and  concepts  are  explained  in  the  glossary. 

Note:   The  term  "system"  is  used  loosely  to  mean  any  collection  of  components, 
hardware,  software,  firmware,  processes,  etc.  The  use  of  a  more  specific  term  is 
recommended.   Terms  such  as  "the  offeror's  solution"  for  integration  efforts,  "the 
product"  for  a  component  buy,  "application  system,"  "operating  system,"  or  specific 
references  to  parts  of  the  system  architecture,  i.e.,  "trusted  computing  base,"  are  a 
few  examples. 
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Note:   The  controls  are  consistent  with  those  specified  in  DoD's  5200.28-STD.  See 
NCSL  Bulletin  Guidance  to  Federal  Agencies  on  the  Use  of  Trusted  Systems 
Technology. 

J.l.    Identification  and  Authentication  Specifications 

Identification  and  authentication  are  basic  building  blocks  of  security  features  in 
systems.   For  many  systems,  every  user  initiated  activity  within  the  computer  system 
(e.g.,  accessing  or  printing  a  file,  sending  a  message)  should  be  attributable  to  a  user 
of  the  system.   The  identification  is  normally  performed  when  the  user  logs  on  to 
the  system,  whether  through  an  interactive  terminal,  or  through  some  other 
mechanism  (e.g.,  using  a  batch  job,  through  a  network  connection).  User 
authentication  is  normally  performed  by  use  of  a  password.   However,  there  are 
many  methods  of  authentication.   To  enforce  accountability  and  access  control,  all 
users  must  identify  and  authenticate  themselves  to  the  system. 

The  system  shall  include  a  mechanism  to  require  users  to  uniquely 
identify  themselves  to  the  system  before  beginning  to  perform  any 
other  actions  that  the  system  is  expected  to  mediate.  Furthermore, 
the  system  shall  be  able  to  maintain  authentication  data  that 
includes  information  for  verifying  the  identity  of  individual  users 
(e.g.,  passwords).     The  system  shall  protect  authentication  data  so 
that  it  cannot  be  accessed  by  any  unauthorized  user.     The  system 
shall  be  able  to  enforce  individual  accountability  by  providing  the 
capability  to  uniquely  identify  each  individual  computer  system 
user.     The  system  shall  also  provide  the  capability  of  associating 
this  identity  with  all  auditable  actions  taken  by  that  individual. 
The  system  shall  be  able  to  maintain  information  for  determining  the 
authorizations  of  individual  users. 

The  type  of  user  authentication  mechanism  may  need  to  be  specified.  The  most 
common  type  of  authentication  is  passwords.   NIST  FIPS  PUB  112  Standard  on 
Password  Usage  is  a  mandatory  standard.   In  addition,  DoD  CSC-STD-00-85 
Password  Management  Guideline  contains  further  information  on  passwords. 

There  are  several  other  types  of  authentication  mechanisms.   User  authentication  can 
be  based  on  three  categories  of  information:   something  the  user  knows,  such  as  a 
password;  something  the  user  possesses,  such  as  a  token;  and  some  physical 
characteristic  (biometric)  of  the  user,  such  as  a  fingerprint.   Authentication  methods 
employing  a  token  or  biometric  can  provide  a  significantly  higher  level  of  security 
than  passwords  alone.  These  systems  are  referred  to  as  advanced  authentication 
technology.   In  addition,  cryptography  is  often  incorporated  into  advanced 
authentication  systems  especially  in  network  applications.   NIST  will  be  providing 
guidance  on  advanced  authentication. 
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J.2.    Discretionary  Access  Control  Specifications 

Computer  systems  access  control  is  the  mechanism  used  to  specify  "who"  (subjects) 
can  do  "what"  to  items  controlled  by  the  system  or  application  (objects).  The  most 
common  types  of  access  are  read,  write,  modify,  execute,  and  delete.  The  access 
control  is  said  to  be  discretionary  when  users  on  the  system  can  pass  access 
permissions  to  other  users.   This  can  be  done  directly  or  indirectly,  such  as  copying 
a  file  to  a  public  area  on  the  system. 

(Note:   The  term  "access  control"  is  also  used  to  refer  to  physical  controls.  This 
section  addresses  the  logical  access  provided  by  the  computer  system.) 

The  system  shall  use  identification  and  authorization  data  to 
determine  user  access  to  information.     The  system  shall  be  able  to 
define  and  control  access  between  subjects  and  objects  in  the 
computer  system.     The  enforcement  mechanism   (e.g.,    self /group/ 
public  controls,   access  control  lists)   shall  allow  users  to  specify 
and  control  sharing  of  those  objects  by  other  users,   or  defined 
groups  of  users,    or  by  both,   and  shall  provide  controls  to  limit 
propagation  of  access  rights.     The  discretionary  access  control 
mechanism  shall,   either  by  explicit  user  action  or  by  default, 
provide  that  objects  are  protected  from  unauthorized  access.  These 
access  controls  shall  be  capable  of  including  or  excluding  access  to 
the  granularity  of  a  single  user.     Access  permission  to  an  object  by 
users  not  already  possessing  access  permission  shall  only  be 
assigned  by  authorized  users. 

Commercial  systems  vary  significantly  with  respect  to  the  granularity  of  objects  to 
which  discretionary  access  control  is  applied.   Generally,  operating  systems  are 
organized  to  provide  discretionary  access  control  at  the  file  level.   In  order  to 
provide  access  control  within  an  application,  the  government  must  specify  the  types 
of  objects,  such  as  data  elements,  that  are  subject  to  the  access  control. 

If  system  being  acquired  is  to  be  delivered  with  access  controls  established,  then  the 
government  must  provide  a  security  policy,  definition  of  data  objects,  and  list  of 
access  classes,  access  types,  and  accesses  (who  can  do  what)  to  the  data  objects. 

J.3.    Audit  Specifications 

Auditing  provides  protection  in  the  sense  that  all  meaningful  actions  within  the 
system  may  be  recorded  and  some  user  held  accountable  for  each  action.  Auditing 
can  occur  at  the  operating  system  level  or  within  a  database  or  application.  The 
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recorded  audit  data  can  assist  the  system  security  officer  in  determining  who  is 
responsible  for  a  problem  or  how  a  problem  was  caused.   Audit  data  can  be  used  to 
deter  users  from  attempting  to  exceed  their  authorizations  and  to  achieve  individual 
accountability.   The  key  to  accountability  in  computer  and  network  systems  is  the 
recording  and  analysis  of  effective  audit  trail  information. 

Some  system  designers  provide  for  the  auditing  of  an  event  with  mechanisms  that 
cannot  be  turned  off  by  the  operator,  or  system  security  officer.   Other  system 
designers  supply  audit  capabilities  that  can  be  turned  on  or  off  at  the  discretion  of 
the  operator  or  security  officer,  thus  allowing  each  local  site  to  "tune"  its  auditing. 
There  are  a  number  of  tradeoffs  that  must  be  made  in  deciding  what  is  to  be 
audited  and  how  often. 

The  government  is  responsible  for  selecting  which  events  have  the  potential  to  be 
audited  and,  after  system  acquisition,  which  events  are  recorded  in  the  audit  trail. 
The  government  must  also  specify  how  long  audit  information  is  to  be  retained  and 
on  what  media.  These  decisions  should  be  based  on  how  the  audit  data  will  be 
used. 

The  following  is  a  three-part  specification  for  auditing  which  should  be  modified  for 
the  type  of  system  being  procured.   The  first  part  of  the  specification  defines  the 
auditing  function  itself. 


The  system  shall  be  able  to  create, 
modification  or  unauthorized  access 
accesses  to  the  objects  it  protects 
protected  so  that  read  access  to  it 
authorized. 


maintain,   and  protect  from 

or  destruction  an  audit  trail  of 

The  audit  data  shall  be 
is  limited  to  those  who  are 


The  second  part  of  this  specification  lists  what  types  of  events  need  to  be  auditable. 
This  list  should  be  modified  to  include  security  events  relevant  to  the  system 
function  and  environment. 

The  system  shall  be  able  to  record  the  following  types  of  events: 
use  of  identification  and  authentication  mechanisms,   introduction  of 
objects  into  a  user's  address  space   (e.g.,    file  open,  program 
initiation) ,   deletion  of  objects,   and  actions  taken  by  computer 
operators  and  system  administrators  and/or  system  security  officers 
and  other  security  relevant  events.     The  system  shall  also  be  able 
to  audit  any  override  of  human-readable  output  markings. 

The  third  part  of  this  audit  specification  is  a  description  of  the  audit  record. 

For  each  recorded  event,   the  audit  record  shall  be  able  to  identify: 
date  and  time  of  the  event,   user,   type  of  event,   and  success  or 
failure  of  the  event.     For  identification/  authentication  events  the 
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origin  of  request    (e.g.,    terminal  ID)    shall  be  included  in  the  audit 
record.     For  events  that  introduce  an  object  into  a  user's  address 
space  and  for  object  deletion  events,   the  audit  record  shall  include 
the  name  of  the  object  and  the  object's  label.     The  system 
administrator  shall  be  able  to  selectively  audit  the  actions  of  any 
one  or  more  users  based  on  individual  identity  and/or  object  label. 

J.4.    Cryptography  Specifications 

The  following  subsections  address  some  of  the  ways  cryptography  can  be  used  to 
provide  computer  security  services  in  systems  and  some  of  the  considerations  for 
using  cryptography. 

Cryptography  can  be  used  to  provide  confidentiality  and  integrity  protection  and  can 
be  used  in  the  generation  of  electronic  signatures.   Confidentiality  of  information  can 
be  provided  through  encryption,  which  is  the  process  of  transforming  information 
from  a  human  intelligible  form  to  an  unintelligible  form.   Integrity  can  be  provided 
through  message  authentication,  which  is  a  cryptographic  process  used  to  detect 
unauthorized  changes  to  information  (transmitted  or  stored)  in  a  computer  system. 
An  electronic  (cryptographic)  signature  is  used  as  a  replacement  for  a  handwritten 
signature. 

Cryptography  can  be  categorized  as  either  secret  key  or  public  key.   Secret  key 
cryptography  is  based  on  the  use  of  a  single  cryptographic  key  shared  between  two 
parties.   The  same  key  is  used  to  encrypt  and  decrypt  the  data.   Public  key 
cryptography  uses  two  keys:   a  private  key  which  is  known  only  to  its  owner  and  a 
public  key  which  is  distributed.  Either  the  public  or  private  key  can  be  used  to 
encrypt  the  data  and  the  opposite  key  is  used  to  decrypt  it. 

Choosing  which  type  of  cryptography  should  be  implemented  in  a  system  is 
determined  by  several  factors.   An  agency  should  consider  the  requirements  of  the 
application  and  the  types  of  services  which  can  be  provided  by  each  type  of 
cryptography.   It  is  possible  that  both  secret  key  and  public  key  cryptography  are 
needed  in  one  system;  each  performing  different  functions. 

This  section  addresses  three  services  provided  by  cryptography;   encryption,  data 
authentication,  and  electronic  signatures;  and  two  areas  that  must  be  considered  for 
any  system  using  cryptography:   key  management  and  security  of  cryptographic 
modules. 
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J.4.a.  Encryption 


If  encryption  of  sensitive  but  unclassified  information  (except  Warner  Amendment 
information)  is  needed  in  a  federal  information  processing  system  the  use  of  the 
Data  Encryption  Standard  (DES),  FIPS  46-1,  is  required  unless  a  waiver  is  granted 
by  the  head  of  the  federal  agency.  The  NCSL  Bulletin  on  DES  dated  June  1990 
provides  an  overview  of  DES,  addresses  its  applicability,  and  describes  waiver 
procedures.  Procurement  initiators  should  be  aware  that  software  implementations  of 
the  algorithm  for  operational  use  in  general  purpose  computer  systems  currently  do 
not  comply  with  the  standard,  and,  if  used,  a  waiver  is  required. 

NIST  provides  a  validation  service  for  DES.   A  validation  is  required  for 
conformance  with  the  standard.   See  section  4.f  below  and  Appendix  B  for  further 
information  on  validations  and  assurances,  including  contract  language. 

The  encryption  provided  by   (the  system  or  specific  part  of  the 
system  as  defined  in  the  statement  of  work)   shall  be  accomplished  in 
accordance  with  FIPS  46-1  Data  Encryption  Standard.  (Select 
validation  language  from  Appendix  B.) 

In  addition  to  specifying  the  cryptographic  implementation,  agencies  should  consider 
other  technical  variables  such  as  throughput,  system  interfaces,  and  data  format. 
While  DES  can  work  in  any  environment,  the  product  that  implements  the  DES  may 
have  been  customized  for  a  particular  environment. 

Other  important  aspects  of  DES,  such  as  key  management  and  the  security  of  the 
modules,  are  addressed  in  sections  4.d  and  4.e. 


J.4.b.  Data  Authentication 

DES  is  the  basis  for  the  Data  Authentication  Algorithm  defined  in  FIPS  113, 
Computer  Data  Authentication.   The  FIPS  113  provides  integrity  for  information 
using  a  cryptographic  check  value  known  as  the  Message  Authentication  Code 
(MAC).   Applying  the  DES  algorithm,  a  MAC  is  calculated  on  and  appended  to 
information.   To  verify  that  the  information  has  not  been  modified  at  some  later 
time,  the  MAC  is  recalculated  on  the  information.  The  new  MAC  is  compared  with 
the  MAC  that  was  previously  generated  and  if  they  are  equal  then  the  information 
has  not  been  altered.  This  standard  should  be  used  by  agencies  whenever 
cryptographic  authentication  is  needed  for  the  detection  of  intentional  modification  of 
information. 

Note:  FIPS  113  may  be  implemented  in  hardware,  software,  firmware,  or  any 
combination  thereof. 
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NIST  provides  a  validation  service  for  FIPS  113.   Agencies  may  require  that 
offerors  have  products  tested.   For  many  applications,  validation  testing  can  provide 
cost-effective  assurance.   See  section  4.f  below  and  Appendix  B  for  further 
information  on  validations  and  contract  language. 

The  data/message  authentication  provided  by   (the  system  or  specific 
part  of  the  system  as  defined  in  the  statement  of  work)   shall  be 
accomplished  using  message  authentication  codes  as  defined  by  FIPS 
113.      (Select  validation  language  from  Appendix  B.) 

J.4.c.  Electronic  Signature 

Using  cryptography,  an  electronic  signature  capability  has  been  developed  as  a 
replacement  of  the  handwritten  signature.   This  capability  can  be  used  in  ADP 
systems  anywhere  a  signature  is  required.  For  example,  a  signature  may  be  needed 
on  an  electronic  letter,  form,  or  message.   Like  the  handwritten  signature,  the 
electronic  signature  can  be  used  to  identify  the  originator  or  signer  of  ADP 
information.   Unlike  its  written  counterpart,  it  also  verifies  that  information  has  not 
been  altered  after  it  was  electronically  signed. 

An  electronic  signature  can  be  generated  using  public  key  or  secret  key 
cryptography.   Using  a  public  key  system,  documents  in  a  computer  system  are 
electronically  signed  by  applying  the  originator's  private  key  to  the  document.  The 
resulting  digital  signature  and  document  are  usually  stored  or  transmitted  together. 
The  signature  can  be  verified  using  the  public  key  of  the  signer.  If  the  signature 
verifies  properly,  the  receiver  has  confidence  that  the  document  was  signed  by  the 
owner  of  the  public  key  and  that  the  message  has  not  been  altered  after  it  was 
signed.   Because  private  keys  are  known  only  to  their  owner,  it  is  also  possible  to 
verify  the  signer  of  the  information  to  any  third  party.   A  digital  signature, 
therefore,  provides  two  distinct  security  services:   nonrepudiation  and  message 
integrity.   Identifying  that  electronic  information  was  actually  signed  by  the  claimed 
originator  to  a  third  party  provides  nonrepudiation.   Determining  that  information 
was  not  altered  after  it  was  signed  provides  message  integrity.    NIST  currently  has 
a  draft  Digital  Signature  Standard  (DSS),  which  has  not  yet  been  assigned  a  FIPS 
number. 

NIST  is  planning  on  providing  a  validation  service  for  the  DSS.   A  validation  will 
be  required  for  conformance  with  the  standard  after  NIST  establishes  the  validation 
program.   See  section  4.f  below  and  Appendix  B  for  further  information  on 
validations  and  assurances,  including  contract  language. 

The  following  contract  clause  should  not  be  used  until  the  draft  FIPS  is  finalized. 
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The  public  key-based  digital  signature  capability  provided  by  (the 
system  or  specific  part  of  the  system  as  defined  in  the  statement  of 
work)    shall  be  accomplished  in  accordance  with  the  Digital  Signature 
Standard   (insert  FIPS  number).      (Select  validation  language  from 
Appendix  B . ) 

Using  DES,  a  secret  key  algorithm,  a  MAC  (a  cryptographic  check  value)  can  be 
used  to  provide  an  electronic  signature  capability.   Calculating  a  MAC  on 
information  in  an  ADP  system  provides  message  integrity  as  described  in  section  4.b 
above.   A  MAC  can  be  used  to  identify  the  signer  of  information  to  the  receiver. 
However,  the  implementations  of  this  technology  do  not  inherently  provide 
nonrepudiation  because  both  the  sender  of  the  information  and  the  receiver  of 
information  share  the  same  key. 

The  electronic  signature  capability  provided  by   (the  system  or 
specific  part  of  the  system  as  defined  in  the  statement  of  work) 
shall  be  accomplished  in  accordance  with  FIPS  113.  (Select 
validation  language  from  Appendix  B.) 

J.4.d.   Key  Management 

Key  management  is  extremely  important  because  the  security  of  any  cryptographic 
system  is  dependent  on  the  security  provided  to  the  cryptographic  keys.   In  order  for 
a  cryptographic  system  to  work  effectively,  keys  must  be  generated,  distributed, 
used,  and  destroyed  securely.   Key  management  is  an  issue  in  both  secret  key 
systems,  such  as  DES,  and  public  key  systems.  This  section  addresses  secret  key 
systems. 

NIST  has  developed  a  draft  FIPS  PUB  for  the  management  of  cryptographic  keying 
material  utilizing  the  Data  Encryption  Standard.  (A  FIPS  number  has  not  yet  been 
assigned.)  The  draft  FIPS  PUB  adopts  ANSI  X9.17  and  specifies  a  particular 
selection  of  options  for  the  automated  distribution  of  keying  material  by  the  Federal 
Government.   This  standard  must  be  used  by  Federal  agencies  when  designing, 
acquiring,  implementing  and  managing  keying  material  which  use  DES  and  ANSI 
X9.17.   Other  key  management  systems  may  be  approved  by  NIST  for  federal 
government  use  in  the  future. 

NIST  provides  a  validation  service  for  selected  options  of  ANSI  X9.17  and  is 
developing  services  for  the  new  FIPS.   Agencies  may  require  that  offerors  have 
products  tested.  For  many  applications,  validation  testing  can  provide  cost-effective 
assurance.   See  section  4.f  below  and  Appendix  B  for  further  information  on 
validations  and  assurances,  including  contract  language. 
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The  following  contract  clause  should  not  be  used  until  the  draft  FIPS  is  finalized. 
Make  sure  that  the  validation  section  of  the  clause  only  specifies  options  for  which 
NIST  is  currently  providing  validation  services. 

The  key  management  provided  by   (the  system  or  specific  part  of  the 
system  as  defined  in  the  statement  of  work)   shall  be  accomplished  in 
accordance  with   (insert  FIPS  number) . 

Key  management  can  be  a  complex  issue  for  large  or  diverse  systems.   Be  sure  to 
request  a  key  management  system  that  meets  the  system's  specific  needs. 

J.4.e.   Security  of  Cryptographic  Modules 

The  security  of  cryptographic  modules  refers  to  the  secure  design,  implementation 
and  use  of  a  cryptographic  module.   The  security  of  cryptographic  modules  is 
important  because  cryptography  is  often  relied  on  as  the  exclusive  means  of 
protecting  data  when  the  data  is  outside  the  control  of  the  system.  The  protection 
of  the  data  is,  therefore,  reliant  on  the  correct  operation  of  the  cryptographic 
module.   The  knowledge  that  a  module  is  operating  correctly  is  referred  to  as 
assurance.   Appendix  B  and  section  III.B.l.b  further  discuss  assurance. 

Proposed  FIPS  PUB  140-1  Security  Requirements  for  Cryptographic  Standards 
establishes  the  physical  and  logical  security  requirements  for  the  design  and 
manufacture  of  cryptographic  modules  used  to  protect  sensitive  unclassified 
information.   Note:   FIPS  140-1  can  be  used  to  provide  assurance  for  DES  and 
other  NIST-approved  cryptographic  algorithms,  such  as  the  public  key  algorithm 
used  in  the  digital  signature  standard. 

FIPS  140-1  defines  four  levels  of  security,  with  Level  1  being  the  lowest  and  Level 
4  being  the  highest.   Based  on  the  level  of  assurance  analysis  performed  during  the 
security  requirements  phase  (sec.  III.B.l.b),  an  appropriate  FIPS  140-1  level  should 
be  identified.   NIST  may  provide  additional  information  which  will  help  agencies 
identify  the  appropriate  level.   The  identification  of  the  security  level  should  be 
specified  in  the  procurement  package. 

FIPS  140-1  will  replace  FIPS  140,  General  Security  Requirements  for  Equipment 
Using  the  Data  Encryption  Standard  (formerly  Federal  Standard  1027).  Currently 
agencies  must  require  conformance  with  FIPS  140  (or  obtain  a  waiver)  if 
cryptography  is  used  to  protect  sensitive  unclassified  information.   Since  testing  is 
no  longer  available  for  FIPS  140,  agencies  cannot  require  validation  testing.  Instead, 
agencies  should  require  an  offeror's  declaration  of  FIPS  140  conformance  or,  if 
available,  an  NSA  endorsement.   After  FIPS  140-1  becomes  a  standard,  agencies 
should  continue  to  require  a  declaration  of  conformance  until  NIST  establishes  the 
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validation  service.   Only  then  can  agencies  require  FIPS  140-1  validations.  The 
CSL  Bulletin,  "FIPS  140  -  A  Standard  In  Transition,"  dated  April  1991,  provides 
additional  information  on  the  standard  and  the  waiver  procedure. 

When  FIPS  140-1  becomes  a  standard  and  NIST  has  established  the  validation 
program,  the  following  clause  can  be  used.   A  validation  will  be  required  for 
conformance  with  the  standard.   See  section  4.f  below  and  Appendix  B  for  further 
information  on  validations  and  assurances,  including  contract  language.  These 
clauses  should  not  be  used  until  FIPS  140-1  is  finalized. 

The  design,    implementation,   and  use  of  the  cryptographic  module 
provided  by   (the  system  or  specific  part  of  the  system  as  defined  in 
the  statement  of  work)    shall  be  in  conformance  with  FIPS  140-1, 
Level    (insert  level).      (Select  validation  language  from  Appendix  B.) 

J.4.f.  Validations 

NIST  currently  provides  validation  services  for  FIPS  46-1,  FIPS  113,  and  selected 
options  of  ANSI  X9.17.   After  an  implementation  is  validated,  NIST  issues  a 
validation  certificate  and  adds  the  implementation  to  a  Validation  List.   (Lists  for 
validated  implementations  are  available  by  contacting  NIST  or  through  their 
electronic  bulletin  board  service,  301-948-5717  or  from  the  NIST  Validated  Products 
List,  updated  quarterly.)  Manufacturers,  integrators,  and  offerors  may  purchase 
validated  implementations  and  use  them  in  their  own  products.   As  long  as  the 
validated  implementation  has  not  been  altered,  a  second  validation  is  not  performed. 
Therefore,  the  product  containing  the  validated  implementation  would  not  be  on  the 
validation  list;  however,  the  offeror  should  be  able  to  identify  the  validated 
implementation  used  in  the  product  or  supply  a  copy  of  the  original  validation 
certificate. 

See  Appendix  B  for  more  information  on  validations  and  assurance.   Appendix  B 
specifically  addresses  options  for  validation  testing  and  provides  contract  language. 


Other  Sources 

NIST  has  other  standards  and  guidelines  that  relate  to  cryptography.   A  list  of  NIST 
publications  is  available  from  NIST  Publications  List  91.   For  ordering  information, 
see  the  inside  back  cover  of  this  document. 
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J.5.    Object  Reuse  Specifications 


When  a  system  resource  (memory  or  storage)  is  reused,  there  is  a  possibility  that  the 
new  user  can  view  "residual  information"  left  in  the  resource  by  the  previous  user. 
The  purpose  of  object  reuse  specifications  is  to  prevent  the  inadvertent  disclosure  of 
residual  information.   Since  object  reuse  may  impact  system  performance,  care 
should  be  taken  in  selecting  and  testing  object  reuse. 

The  system  shall  be  able  to  ensure  that  all  authorizations  to  the 
information  contained  within  an  object  are  revoked  prior  to  initial 
assignment,   allocation  or  reallocation  to  a  subject  from  the 
system's  pool  of  unused  objects.     The  system  shall  be  able  to  ensure 
that  no  information,    including  encrypted  representations  of 
information,   produced  by  a  prior  subject's  actions  is  available  to 
any  subject  that  obtains  access  to  an  object  that  has  been  released 
back  to  the  system. 

Object  reuse  specifications  can  be  achieved  either  by  clearing  objects  upon  allocation 
or  upon  deallocation.  A  third  method  involves  establishing  a  "high  water  mark" 
sensitivity  of  the  object,  allocating  it  only  to  processes  of  the  same  sensitivity. 
Objects  can  be  cleared  by  overwriting  each  bit  in  the  object.    The  minimum 
number  of  overwrites  should  be  specified. 

J.6.    System  Integrity  Specifications 

The  government  can  use  commercial  off-the-shelf  diagnostic  capability  for  validating 
correctness  of  the  hardware  and  firmware  operations.   Generally  speaking  such 
diagnostic  offerings  are  not  valid  to  verify  the  correctness  of  the  software 
implementation. 

Hardware  and/or  software  features  shall  be  provided  that  can  be  used 
to  periodically  validate  the  correct  operation  of  the  on-site 
hardware  and  firmware  elements  of  the  system. 

In  addition,  some  vendors  are  using  cryptographic  techniques  to  verify  the  integrity 
of  their  software.   These  can  be  used  to  ensure  that  software  received,  or  in  storage, 
is  the  same  as  the  "master"  copy  of  the  software  maintained  by  the  vendor. 

J.7.    System  Architecture  Specifications 

As  described  in  Appendix  B,  "Assurance,"  the  use  of  advanced  system  architectures 
can  provide  assurance  that  the  security  features  are  correctly  and  effectively 
implemented. 
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The  mechanisms  within  the  application  that  enforce  the  access 
control  shall  be  continuously  protected  against  tampering  and/or 
unauthorized  changes. 

The  security-relevant  software  shall  maintain  a  domain  for  its  own 
execution  that  protects  its  security  mechanisms  from  external 
interference  or  tampering   (e.g.,   by  modification  of  its  code  or  data 
structures) .     Resources  controlled  by  the  system  may  be  a  defined 
subset  of  the  subjects  and  objects  in  the  computer  system.  The 
system  shall  maintain  process  isolation  through  the  provision  of 
distinct  address  spaces  under  its  control.     The  system  shall  isolate 
the  resources  to  be  protected  so  they  are  controlled  by  the  access 
control  and  auditing  requirements. 

Note:   The  word  "domain"  as  used  here  refers  to  the  protection  environment  in 
which  a  process  is  executing.  Domain  is  sometimes  also  referred  to  as  "context"  or 
"address  space." 

The  procuring  agency  should  be  aware  that  over  specification  of  the  architecture  for 
a  system  can  preclude  integrators  from  incorporating  otherwise  valid  existing 
products.  Over  specification  can  also  eliminate  lower  cost  alternatives  resulting  in  a 
more  costly  procurement.  This  over  specification  is  a  common  problem  and 
generally  proves  not  to  be  cost  effective.  From  a  security  perspective  over 
specification  can  actually  preclude  adequate  information  control. 

J.8.    Labels  and  Mandatory  Access  Control 

The  following  sections  address  labels  and  mandatory  access  control.  These  are 
emerging  security  features  in  some  off-the-shelf  operating  systems  which  may  be 
appropriate  for  use  in  some  computing  environments.   They  are  not  required. 

This  section  presents  a  brief  introduction  to  and  specification  language  for  labels  and 
mandatory  access  control.   Labels  and  mandatory  access  control  should  not  be 
acquired  or  implemented  without  a  thorough  knowledge  of  access  control  policy, 
information  flow,  and  how  labels  and  mandatory  access  control  work.  Labels  and 
mandatory  access  control  can  be  costly  in  terms  of  dollars,  ease  of  use,  ease  of 
administration,  and  computer  resources. 

These  sections  on  labels  and  mandatory  access  control  are  addressing  only  one  form 
of  mandatory  access.   Other  approaches,  such  as  those  based  on  roles,  are  possible, 
section  J.9  addresses  labels;  section  J.  10  addresses  mandatory  access  controls.  For 
additional  guidance,  the  procurement  initiator  should  contact  the  agency  security 
official. 
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Labels  and  mandatory  access  control  are  useful  when  acquiring  multi-user  computer 
systems  with  a  requirement  for  mandatory  separation  of  sensitive  information  and  for 
which  security  labels  can  be  established.   In  practical  terms,  this  means  labels  and 
mandatory  access  control  are  most  useful  if  the  type  and  degree  of  sensitivity  of  the 
data  can  be  established,  and  there  is  a  strong  reason  for  using  technical  means  to 
enforce  compliance  with  policy.  Labeling  and  mandatory  access  control  require  that 
there  is  a  clear  access  control  policy  that  can  be  enforced. 

J.9.    Label  Specifications 

Labels  can  be  used  to  have  the  system  manage  sensitive  objects.   A  label  is  a  piece 
of  information  that  represents  information  about  an  object  or  subject.   Labels  can  be 
used  for  a  variety  of  purposes  including  access  control,  specifying  protective 
measures,  and  indicating  additional  handling  instructions.  This  document  addresses 
using  labels  for  access  control.  It  should  be  modified  if  the  labels  will  be  used  for 
other  purposes.   If  labels  are  used  for  access  control,  then  object  labels  represent  the 
degree  and  type  of  sensitivity  of  the  data  in  an  object.   Subject  labels  represent  the 
authorization  of  users  to  access  degrees  and  types  of  sensitive  data. 

Security  labels  associated  with  each  subject  and  storage  object 
under  the  system's  control   (e.g.,  process,   file,   segment,  device) 
shall  be  maintained  by  the  system.     These  labels  shall  be  used  as 
the  basis  for  access  control  decisions.     In  order  to  import 
nonlabeled  data,   the  system  shall  be  able  to  request  and  receive 
from  an  authorized  user   (e.g.,   system  or  application  security 
administrator)    the  security  label  of  the  data,   and  all  such  actions 
shall  be  auditable  by  the  system. 

In  order  to  ensure  smooth  transition  in  the  operating  conditions  of  the  system  when 
changes  are  necessary,  and  also  for  maintenance  purposes,  it  is  sometimes  necessary 
to  provide  capabilities  that  allow  the  security  labels  of  objects  to  be  altered  under 
carefully  controlled  conditions. 

The  system  shall  ensure  that  any  feature  that  changes  security 
labels  is  only  invocable  by  an  authorized  individual  under  the 
direct  control  of  the  system,   or  by  a  part  of  the  system,   and  that 
these  actions  are  subject  to  auditing  requirements. 

J.9.a.   Label  Integrity  Specifications 

The  following  specification  addresses  integrity  requirements  for  labels.  Depending 
on  system  architecture,  it  is  not  essential  that  a  label  be  maintained  with  the  data. 
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It  is  permissible  to  associate  the  label  with  the  data.   Some  operating  systems 
maintain  the  label  inside  the  operating  system  and  store  the  data  separately. 

Security  labels  shall  accurately  represent  the  degree  and  type  of 
sensitivity  of  the  specific  subjects  or  objects  with  which  they  are 
associated.     Throughout  the  system,   security  labels  shall  accurately 
and  unambiguously  represent  and  be  associated  with  the  information 
being  managed. 

J.9.b.  Labels  and  Input/Output  Specifications 

Since  all  systems  receive  input  (import  data)  and  produce  output  (export  data),  the 
system  designer  must  address  the  problem  of  what  to  do  with  labels  at  system 
boundaries.   How  is  incoming  data  labeled?   How  is  outgoing  data  labeled?  The 
input  and  output  can  be  in  electronic,  paper,  or  other  form. 

The  system  shall  be  able  to  designate  each  communication  channel  and 
I/O  device  as  either  single-label  or  multi-label.     Any  change  in 
this  designation  shall  be  done  by  a  properly  authorized  individual 
and  shall  be  audi table  by  the  system.     The  system  shall  maintain  and 
be  able  to  audit  any  change  in  the  security  label  or  labels 
associated  with  a  communication  channel  or  I/O  device. 

The  Phrase  "Properly  Authorized"  is  understood  to  be  the  System  Administrator  and 
Security  Officer  or  their  designees. 

J.9.b(l)  Multi-Label  Communications 

When  information  contained  in  an  object  is  exported  from  the  system,  a  means  must 
be  provided  for  the  system  to  accurately  and  unambiguously  associate  the  security 
label  of  the  object  with  the  information  being  exported.  The  Phrase  "exported  by 
the  system"  is  understood  to  include  transmission  of  information  from  an  object  in 
one  system  to  an  object  in  another  system.  The  form  of  internal  security  labels  may 
differ  from  their  external  (exported)  form,  but  the  meaning  must  be  retained.  This 
association  is  critical  on  multi-label  channels  because  the  receiver  will  use  the 
provided  label  both  for  processing  and  access  decisions. 

When  the  system  exports  an  object  to  a  multi-label  I/O  device,  the 
security  label  associated  with  that  object  shall  also  be  exported 
and  shall  reside  on  the  same  physical  medium  as  the  exported 
information  and  shall  be  in  the  same  form  (i.e.,  machine-readable  or 
human-readable  form) .     When  the  system  exports  or  imports  an  object 
over  a  multi-label  communication  channel,   the  protocol  used  on  that 
channel  shall  provide  for  the  unambiguous  pairing  between  the 
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security  labels  and  the  associated  information  that  is  sent  or 
received . 


J.9.b(2)   Single-Label  Communications 

Two  types  of  single  label  designations  are  possible.   One  type  can  be  applied  to  a 
channel  or  device  by  a  Security  Administrator.  The  second  type  can  be  applied  by 
an  authorized  user  (e.g.,  application  security  administrator)  who  can  designate  which 
label,  within  a  range,  is  to  be  applied  to  the  subsequent  data/object.  Thus  a  device 
or  channel  may  be  multiple  consecutive  single  labels;  but  the  system  must 
communicate  with  an  authorized  user  prior  to  each  label  designation  change. 

Single-label  I/O  devices  and  single-label  communication  channels  are 
not  required  to  maintain  the  security  labels  of  the  information  they 
process.  However,  the  system  shall  include  a  mechanism  by  which  the 
system  and  an  authorized  user  (e.g.,  application  security 
administrator)  reliably  communicate  to  designate  the  single  security 
label  of  information  imported  or  exported  via  single-label 
communication  channels  or  I/O  devices. 


J.9.b(3)   Labeling  Output 

The  following  specifications  address  exporting  data  to  a  different  environment,  for 
example,  from  the  internal  system  environment  to  the  office  environment  or  a 
networked  environment. 

Prior  to  releasing  an  object  to  an  environment  where  accesses  are  no 
longer  mediated  by  the  system,   the  system  must  associate  the  object 
with  an  external  label  that  is  comprehensible  to  the  new 
environment.     The  external  label  must  accurately  represent  the 
security  label  of  the  object  as  assigned  by  the  system. 

One  of  the  most  common  examples  of  moving  a  label  into  a  new  environment  is 
labeling  human-readable  output,  specifically  printouts.   The  following  specification  is 
an  example  of  how  the  system  can  label  printouts. 

The  system  administrator  shall  be  able  to  specify  the  printable 
label  names  associated  with  exported  security  labels.     The  system 
shall  mark  the  beginning  and  end  of  all  human-readable,  paged, 
hardcopy  output   (e.g.,    line  printer  output)  with  human-readable 
security  labels  that  properly  represent  the  overall  sensitivity  of 
the  output.     The  system  shall,   by  default,   mark  the  top  and  bottom 
of  each  page  of  human-readable,  paged,   hardcopy  output   (e.g.,  line 
printer  output)   with  human- readable  security  labels  that  properly 
represent  the  overall  sensitivity  of  the  output  or  that  properly 
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represent  the  sensitivity  of  the  information  on  the  page.  The 
system  shall,   by  default  and  in  an  appropriate  manner,  mark  other 
forms  of  human-readable  output   (e.g.,  maps,   graphics)  with 
human-readable  security  labels  that  properly  represent  the 
sensitivity  of  the  output.     Any  override  of  these  marking  defaults 
shall  be  auditable  by  the  system. 

The  system  administrator  is  usually  the  "user"  designated  to  specify  the  printed  or 
displayed  security  label  that  is  to  be  associated  with  exported  information. 

J.10.  Mandatory  Access  Control  Specifications 

As  stated  in  section  2,  access  control  is  the  mechanism  used  to  specify  "who"  can 
do  "what"  to  items  controlled  by  the  system.  The  most  common  types  of  access  are 
read,  write,  modify,  execute,  and  delete.   The  access  control  is  said  to  be  mandatory 
when  the  system  mediates  access  based  on  subject  and  object  labels.  This  prevents 
users  from  accidentally  or  deliberately  violating  the  access  control  policy. 

The  system  shall  be  able  to  enforce  a  mandatory  access  control 
policy  over  all  subjects  and  storage  objects   (e.g.,  processes, 
files,   segments,   devices) .     These  subjects  and  objects  shall  be 
assigned  security  labels  and  shall  be  used  as  the  basis  for 
mandatory  access  control  decisions.     The  system  shall  be  able  to 
support  two  or  more  such  labels.     The  following  requirements  shall 
hold  for  all  accesses  between  subjects  and  objects  controlled  by  the 
system : 

A  subject  can  read  an  object  only  if  the  hierarchical  attribute 
in  the  subject's  label  is  greater  than  or  equal  to  the 
hierarchical  attribute  in  the  object's  label  and  the 
nonhierarchical  attribute  in  the  subject's  label  include  all 
the  nonhierarchical  attributes  in  the  object's  label. 

A  subject  can  write  an  object  only  if  the  hierarchical 
attribute  in  the  subject's  label  is  less  than  or  equal  to  the 
hierarchical  attribute  in  the  object's  label  and  all  the 
nonhierarchical  attributes  in  the  subject's  label  are  included 
in  the  nonhierarchical  labels  in  the  object's  label. 

Identification  shall  be  used  by  the  system  to  ensure  that  the 
authorization  of  subjects  created  to  act  on  behalf  of  the 
individual  user  are  a  subset  of  the  authorization  of  that  user. 
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Appendix  A 


Uniform  Contract  Format  for  Federal  Government 
Requests  For  Proposals  (RFP) 


RFP  Section 


Contents 


Created  By  Technical 
and/or  Procurement 

Comments 


A.  Solicitation/Contract 
Form 


Cover  Sheet  For  RFP,  with 
Solicitation  Number, 
Type  of  Solicitation, 
Due  Date, 

Procurement  Contact 
Point,  etc.  (SF33) 


B.   Supplies  or  Services   List  of  Products/Services 
and  Prices/Costs     to  Be  Provided  by  Offeror 


Procurement 

Contains  standard  RFP 
information 


Procurement 

Developed  from  other 
portions  of  RFP. 
Contains  standard  RFP 
information. 


C.  Description/ 

Specifications/ 
Work  Statement 


D. 


E. 


Packaging  and 
Marking 


Inspection  and 
Acceptance 


Defines  Scope  of  Contract 
and  Requirements  Including: 
Mandatory  Specifications, 
Optional  Features  Services 
Specification  may  be  included 
as  an  Attachment/Section  J 

Shipping,  Handling,  and 
Storage  Requirements. 
May  Not  Be  Required  For 
Service  Contracts. 


Standards  of  Performance, 
Reliability  Requirements, 
Acceptance,  Benchmarks, 
Inspection,  Quality  Assurance 


Technical  &  Procurement 

Describes  product/services 
to  be  procured. 


Procurement  &  Technical 

Standard  RFP  information 
with  special  technical 
requirements  if  necessary. 

Procurement  &  Technical 

Determines  how  product 
or  service  is  to  be 
accepted  and  must 
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Deliveries  or 
Performance 


Time,  Place,  and  Method  of 
Deliverables/Performance. 
Describes  such  things  as: 
Liquidated  Damages, 
Equipment  Replacement, 
Field  Modifications, 
Alternations,  Maintenance 
Response  Time  and  Down  Time 
Credits,  Product  Replacement, 
Variation  in  Quantity, 
Delivery  and  Installation 
Schedule,  Stop  Work  Orders, 
Etc. 


perform.  Contains 
standard  RFP  information 
with  specific  technical 
requirements. 

Procurement  &  Technical 

Contains  standard  RFP 
information  with  special 
technical  requirements. 


G.  Contract 

Administration 
Data 


Contract  Administration  such 

as: 

Authorities  of  Government 
Personnel,  Required  Reports, 
Holidays,  Use  of  Government 
Property,  Financial 
Information 


Procurement  &  usually 
Technical 

Normally  standard  RFP 
information  with  special 
technical  requirements. 


H.   Special  Contract 
Requirements 


I.   Contract  Clauses 


Clauses  Other  Than  Those 
Required  By  Law/Regulations 
Including: 

Warranties,  Replacement 
Parts,  Engineering  Changes 
Recording  Devices, 
Hardware/Software  Monitors, 
Site  Preparation,  Financial 
Reporting,  Transition 
Requirements,  Handling  of 
Data,  Security,  Etc. 

Clauses  Required  By  Law/ 
Regulations  not  Otherwise 
Required  for  a  Particular 
Section. 


Procurement  &  Technical 

Normally  standard  RFP 
information  with  special 
technical  requirements. 


Procurement 

Contains  standard  RFP 
information 
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J.   List  of  Attachments 


K.  Representations, 

Certifications,  and 
Other  Statements 
of  Offerors 


L. 


M.  Evaluation  Factors 
For  Award 


Any  Additional  Procurement 
and  Technical  Information 
For  Offeror. 

All  Statements  Required  of 
the  Offeror  by  Law/ 
Regulation/Agency . 

Offeror  Must  Complete  and 
Return  with  proposal. 


Describes  How  Proposals 
Will  Be  Evaluated  and  the 
criteria  against  which 
proposal  will  be  evaluated. 
Also  Describes  how  a  Source 
will  be  selected. 


Procurement  &  Technical 


Procurement 

Standard  RFP  information 


Procurement  &  Technical 

Addresses  how  offeror 
should  respond  to 
statement  of  work  as  set 
out  in  the  evaluation 
criteria. 


Procurement  &  Technical 


Instructions,  Requirements  for  Proposals. 

Conditions,  and      Specifies  the  Plans, 
Notices  to  Offerors  Approaches,  References,  and 

Other  Information  the 
Offeror  Must  Submit  for 

Proposal  Evaluation. 
Requires  Offeror  To  Tell 
How  They  Will/Can  Meet  The 
Requirements  Described  In 
Section  C. 


For  further  information,  see  FAR  15.406. 
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Assurance 


Appendix  B 


There  are  many  methods  of  attaining  assurance  that  the  security  features  work  as 
proposed.   Since  assurance  methods  tend  to  be  qualitative  rather  than  quantitative, 
they  will  need  to  be  evaluated.   Assurance  can  also  be  quite  expensive,  especially  if 
extensive  testing  is  done.   It  is  useful  to  evaluate  the  amount  of  assurance  received 
against  the  cost  to  make  a  best  value  decision.  It  is  important  to  consider  assurance 
methods  within  the  context  of  the  statement  of  work,  evaluation  plan,  and 
acceptance  test  plan. 

The  selection  of  assurance  methods  should  be  consistent  with  and  follow  from  the 
requirements  analysis,  especially  from  the  risk  analysis.   Since  some  of  the  methods 
are  impossible  for  certain  types  of  federal  information  processing  (FIP)  acquisition  or 
are  restrictive  of  competition,  care  must  be  taken  in  selection.     See  the  note  on 
assurance  and  competition  at  the  end  of  this  appendix. 

It  will  normally  be  best  to  use  a  combination  of  methods.  Each  method  has 
strengths  and  weaknesses  in  terms  of  cost  and  what  kind  of  assurance  is  actually 
being  delivered.   None  are  foolproof.  Each  method  has  restrictions.   An  accrediting 
and/or  certifying  official  or  computer  security  official  can  help  determine  the 
strengths  and  weaknesses  of  each  method  based  on  the  type  of  system(s)  being 
procured. 

Many  of  these  assurances  are  evaluations.  Care  must  be  taken  to  know  what 
evaluation  criteria  were  used  and  exactly  what  the  evaluation  means.  Evaluations 
and  testing  all  have  limits.  No  organization  can  afford  to  test  every  possibility 
including  how  the  evaluated  item  interacts  with  other  system  components. 

Methods 

Testing/quality  assurance.  There  are  many  techniques  that  have  been  developed 
for  use  with  "critical"  or  high  assurance  systems.  These  techniques  can  be  applied 
to  security  software.  These  development  and  acceptance  techniques  provide 
assurance  for  systems.  The  following  NIST  publications  provide  further  explanation: 

FIPS  PUB  101       Guideline  for  Lifecycle  Validation,  Verification,  and 

Testing  of  Computer  Software 
FIPS  PUB  132       Guideline  for  Software  Verification  and  Validation  Plans 
SP  500-144  Guidance  on  Software  Package  Selection 
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SP  500-165  Software  Verification  and  Validation:  Its  Role  in 

Computer  Assurance  and  Its  Relationship  with  Software 
Product  Management  Standards 

SP  500-180  Guide  to  Software  Acceptance 

Agency  quality  assurance,  safety,  or  reliability  personnel  may  also  be  able  to  provide 
assistance.  The  contractor  developing  the  system  or  application  can  provide  security 
testing.   The  development  and  acceptance  testing  can  also  be  done  by  an 
independent  validation  and  verification  contractor  (IV&V).   If  testing  is  going  to  be 
done  by  an  independent  contractor,  this  needs  to  be  specified  in  the  RFP. 

NIST  conformance  testing  and  validation  suites.  NIST  produces  validation  suites 
and  conformance  testing  to  determine  if  a  product  (software,  hardware,  firmware) 
meets  specified  standards.  These  test  suites  are  developed  for  specific  projects  and 
use  many  methods.   New  test  suites  are  being  developed.   In  general,  testing  is 
performed  by  the  vendor  and  validated  by  NIST,  or  testing  is  performed  by  a 
certified  laboratory.   Following  are  examples  of  two  types  of  NIST  computer 
security  testing: 

DES  implementation  testing  (reference  Special  Publication  500-20).  To 
validate  the  correctness  of  the  implementation,  vendors  run  specified  tests  and 
send  the  results  to  NIST.   If  the  vendor  passes  the  test,  NIST  issues  a 
validation  certificate. 

FIPS  PUB  113  data  authentication  algorithm  testing  and  ANSI  X9.17  key 
management  for  point-to-point  environments.   Vendors  connect  to  a  NIST 
bulletin  board  that  interactively  runs  the  test  suite  for  the  selected  standard. 
If  the  vendor  passes  the  test,  NIST  issues  a  validation  certificate. 

Evaluations  by  government  agencies.  Government  agencies  evaluate  products  for 
use  in  their  environments.   These  evaluations  may  or  may  not  be  published.   It  is 
important  to  ask  offerors  to  supply  evaluation  results  as  part  of  an  assurance 
package.  These  evaluations  are  normally  not  endorsements  by  the  agencies. 

NSA's  Evaluated  Products  List  (EPL).  The  National  Security  Agency 
(NSA)  evaluates  some  computer  operating  systems  and  security  packages 
against  DoD  5200.28-STD,  Trusted  Computer  Systems  Evaluation  Criteria 
(TCSEC  or  Orange  Book). 

Evaluations  by  independent  organizations.  Trade  and  professional  organizations 
are  possible  sources  of  independent  evaluations.   Ask  offerors  to  provide  information 
on  evaluations  which  they  consider  pertinent  to  their  proposal. 
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Evaluations  by  another  vendor.  Private  commercial  organizations  may  offer 
product  assurance  testing  and  evaluations.   These  may  lack  the  independence  of 
government  and  trade  organization  evaluations. 

Evaluations  by  another  government.  Other  governments,  including  several 
European  governments  and  Canada,  are  researching  evaluation  techniques  and 
criteria.   Care  should  be  taken  to  observe  the  differences  in  environments  and 
governmental  priorities. 

Product  has  been  accredited  to  operate  in  similar  situation.  Once  again,  these 
accreditations  are  not  published.  It  is  important  to  ask  offerors  to  supply  the 
accreditation  results.  These,  even  more  so  than  evaluations,  are  not  normally 
endorsements.   Accreditations  are  environment  and  system  specific.  Since 
accreditation  balance  risk  against  advantages,  the  same  product  may  be  accredited 
for  one  environment  but  not  for  another. 

Self-certification  following  a  formal  procedure,  e.g.,  FIPS  102.  A  vendor  self- 
certification  does  not  rely  on  the  work  of  an  impartial  or  independent  reviewer.  It 
is  a  vendor's  technical  evaluation  of  a  system  to  see  how  well  it  meets  an  internally 
stated  security  requirement.   Even  though  this  method  does  not  provide  an  impartial 
review,  it  can  still  provide  some  assurance.  The  vendor's  reputation  is  put  on  the 
line  and  a  certification  report  can  be  read  to  determine  if  the  security  requirement 
was  defined  and  if  a  meaningful  review  was  performed. 

Self-certification  under  the  auspices/review  of  an  independent  organization. 

This  method  may  be  able  to  combine  the  lower  cost  and  greater  speed  of  a  self- 
certification  with  the  impartiality  of  an  independent  review.   The  review,  however, 
may  not  be  as  thorough  as  an  evaluation  or  testing. 

Warranties,  Integrity  Statements  and  Liabilities.  Warranties  are  another  source  of 
assurance.  If  a  manufacturer/producer  is  willing  to  correct  errors  within  certain  time 
frames  or  by  the  next  release,  this  should  give  the  purchaser  a  sense  of  commitment 
to  the  product  and  of  product  quality.  An  integrity  statement  is  a  formal  declaration 
or  certification  of  the  product.  It  can  be  backed  up  by  a  promise  to  (a)  fix  the  item 
(warranty)  or  (b)  pay  for  losses  (liability)  if  the  product  does  not  conform  to  the 
integrity  statement.   See  section  IV.E,  "Legal  Issues,"  for  more  information. 

Manufacturer's  published  assertions.  A  manufacturer's  or  developer's  published 
assertion  or  formal  declaration  provides  assurance  based  on  their  reputation. 

Assurance  documentation.  There  are  several  types  of  assurance  documentation. 
Descriptions  are  provided  in  section  IV.D,  "Documentation." 
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Use  of  advanced  or  trusted  development.  Offerors  may  provide  documentation  to 
show  that  they  have  used  advanced  or  trusted  system  architectures,  development 
methodologies,  or  software  engineering  techniques.  Use  of  the  trusted  computing 
base  (TCB)  concept,  formal  modeling,  and  mathematical  proofs  are  some  examples. 
Offerors  should  describe  how  these  techniques  and  methodologies  were  employed 
and  how  they  help  protect  the  system.   (A  specification  for  a  trusted  computer  base 
architecture  is  included  in  "Features  in  Systems,"  sec.  IV.J.7.) 

Assurance  Methods  and  Competition. 

Since  not  all  assurance  methods  are  equally  available  to  all  vendors,  requiring  any 
one  assurance  method  can  limit  competition.  This  is  especially  true  for  evaluations. 
If  the  government  specifies  that  a  product  pass  a  certain  test  to  get  on  a  list  of 
"qualified"  products  before  it  is  acquired,  then  there  may  be  special  rules  that  must 
be  followed.   FAR  9.2  addresses  qualified  products. 

The  government,  according  to  a  basic  procurement  philosophy,  tries  to  maintain  a 
"level  playing  field"  while  providing  incentive  for  vendors  to  provide  advanced 
products.   Requiring  that  a  vendor  use  an  assurance  method  that  is  not  accessible  by 
all  vendors  limits  competition  and  may  preclude  the  government  from  considering 
new  ideas. 

There  are  many  methods  for  increasing  competition  while  still  meeting  the 
government's  requirements.  Discuss  with  the  contracting  officer  the  use  of  scoring 
assurance  methods  or  providing  incentives  and  disincentives.  These  can  be  used  to 
"give  credit"  to  offerors  who  have  had  their  products  evaluated  while  maintaining 
full  and  open  competition. 

Note:  In  a  scoring  scheme,  it  must  be  possible  for  an  offeror  to  gain  the  maximum 
number  of  points  possible  using  assurance  methods  that  are  equally  accessible  to  all. 

Contract  Language  for  Validation  Testing 

The  following  considerations  and  contract  language,  based  on  the  Federal  ADP  & 
Telecommunications  Standards  Index,  can  be  used  to  help  increase  assurance  and 
promote  competition.   Although  the  clauses  are  addressed  to  the  use  of  NIST 
conformance  and  validation  testing,  they  can  be  modified  for  use  with  other  forms 
of  assurance.   (Note:   Some  NIST  validations,  such  as  DES  validations,  are  required 
and  some  are  optional.) 

Testing  and  validations  can  be  performed  at  several  stages  during  an  acquisition. 
These  clauses  address  three  types  of  testing:   delayed  validation,  prior  validation 
testing,  and  prior  validation.  For  delayed  validation  and  prior  validation  testing,  be 
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sure  to  customize  the  time  frame  parameter  in  Part  2  of  the  solicitation  wording  to 
ensure  that  any  resubmissions  for  validations  are  done  in  a  timely  manner. 

Delayed  Validation.  When  an  agency  determines  that  the  nature  of  the  requirement 
is  such  that  implementations  of  a  HPS  may  be  offered  that  have  not  yet  been  tested 
for  conformance  to  that  FIPS  or  if  an  implementation  of  the  FIPS  will  be  developed 
during  the  course  of  the  contract,  the  "Delayed  Validation"  solicitation  wording 
option  should  be  used. 

Prior  Validation  Testing.  When  an  agency  determines  that  it  is  essential  for 
implementation  of  a  FIPS  to  be  previously  tested  for  conformance  to  that  FIPS 
before  being  offered,  and  the  nature  of  the  requirement  is  such  that  an 
implementation  of  a  FIPS  may  be  initially  offered  that  has  not  been  fully  validated 
(i.e.,  implementation  has  not  fully  demonstrated  compliance  to  the  FIPS),  the  "Prior 
Validation  Testing"  solicitation  wording  option  should  be  used.  For  example,  some 
validation  procedures,  especially  for  complex  FIPS,  allow  for  stages  within  the 
process. 

Prior  Validation.  When  an  agency  determines  that  it  is  essential  for 
implementations  of  a  FIPS  be  validated  (i.e.,  implementation  has  been  tested  and  has 
demonstrated  compliance  to  the  FIPS)  for  conformance  to  that  FIPS  prior  to  being 
offered  the  "Prior  Validation"  solicitation  wording  option  should  be  used. 

Solicitation  Wording:   Validation  of  FIPS  Implementations 

This  clause  can  be  modified  to  address  particular  FIPS  and  particular  system 
components.   Within  a  solicitation,  different  testing  options  can  be  specified  for 
different  components. 

In  addition  to  the  FIPS  implementation  requirements  specified 
elsewhere  in  this  requirements  document,   all  implementations  of  FIPS 
that  are  brought  into  the  Federal  inventory  as  a  result  of  this 
document  for  which  validation  is  specified,   and  those  implementation 
used  by  vendors  to  develop  programs  or  provide  services  shall  be 
validated  using  the  official  validation  system  specified  by  the 
National  Institute  of  Standards  and  Technology   (NIST)  Computer 
Systems  Laboratory   (CSL) .     Validation  shall  be  in  accordance  with 
CSL  validation  procedures  for  that  FIPS.     The  results  of  validation 
shall  be  used  to  confirm  that  the  implementation  meets  the 
requirements  of  the  applicable  FIPS  as  specified  in  this  document. 

To  be  considered  responsive  the  offeror  shall: 

(1)   Provide  validated  FIPS  implementation  through   (select  testing 
option  and  insert  appropriate  paragraph  from  below:  "Delayed 
Validation,"   "Prior  Validation  Testing"  or  "Prior  Validation.") 


87 


(2)     Agree  to  correct  all  implementation  nonconformance  from  the 
applicable  FIPS  reflected  in  the  validation  summary  report  not 
previously  covered  by  a  waiver.     All  areas  of  nonconformance  must  be 
corrected  within  12  months   (or  other  time  frame)   from  the  date  of 
contract  award   (or  from  the  date  of  the  summary  report)  unless 
otherwise  specified  in  this  document.     If  an  interpretation  of  the 
FIPS  is  required  that  will  invoke  the  procedures  set  forth  in  FIPS 
PUB  29-2,   such  a  request  for  interpretation  shall  be  made  within  30 
calendar  days  after  contract  award.     Any  corrections  that  are 
required  as  a  result  of  decision  made  under  the  procedures  of  FIPS 
PUB  29-2  shall  be  completed  within  12  months  of  the  date  of  the 
formal  notification  to  the  contractor  of  the  approval  of  the 
interpretation.     Proof  of  correction  in  either  case  shall  be  in  the 
form  of  a  CSL  Certificate  of  Validation  or  registered  validation 
summary  report  for  the  corrected  implementation.     Failure  to  make 
required  corrections  within  the  time  limits  set  forth  above  shall  be 
deemed  a  failure  to  deliver  required  material.     The  liquidated 
damages  as  specified  for  failure  to  deliver  the  operating  system  or 
other  system  component   (software,  hardware  or  firmware)   shall  apply. 

Testing  Options: 

"Delayed  Validation" 

The  offeror  shall  certify  in  the  offer  that  all  implementation 
of  FIPS,   including  applicable  FIPS  options,  offered  or 
developed  in  response  to  this  document  will  be  submitted  for 
validation.       If  the  implementations  are  to  be  developed  they 
shall  be  submitted  for  validation  upon  delivery.     If  the 
implementations  are  available  and  have  not  been  previously 
tested  or  validated  then  the  implementations  shall  be  submitted 
for  validation  upon  contract  award.     In  either  case,  when  the 
implementation  is  submitted  for  validation  the  submission  shall 
include  a  request  to  have  the  validation  be  completed  at  the 
earliest  possible  date  permitted  by  the  CSL  validation 
procedures.     Unless  specified  elsewhere,  proof  of  submission 
for  validation  shall  be  in  the  form  of  a  letter  scheduling  the 
validation  and  the  subsequent  delivery  by  the  offeror  of  a  CSL 
registered  report  or  CSL  certificate  immediately  upon  receipt 
thereof.     Proof  of  testing  shall  be  provided  in  the  form  of  a 
CSL  registered  validation  summary  report.     Proof  of  validation 
shall  be  in  the  form  of  a  CSL  Certificate  of  Validation. 

"Prior  Validation  Testing" 

The  offeror  shall  certify  in  the  offer  that  all  implementations 
of  FIPS,  including  applicable  FIPS  options,  offered  in  response 
to  this  document  have  been  previously  tested  or  validated  and 
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included  on  the  current  list  of  validated  products  maintained 
by  the  Computer  Systems  Laboratory   (CSL) .     Unless  specified 
elsewhere,   proof  of  testing  shall  be  provided  in  the  form  of  a 
CSL  registered  validation  summary  report.     Proof  of  validation 
shall  be  in  the  form  of  a  CSL  Certificate  of  Validation. 

"Prior  Validation" 

The  offeror  shall  certify  in  the  offer  that  all  implementation 
of  FIPS,   including  applicable  FIPS  options,   offered  in  response 
to  this  document  have  been  previously  validated  and  included  on 
the  current  list  of  validated  products  maintained  by  Computer 
Systems  Laboratory   (CSL) .     Unless  specified  elsewhere,  proof  of 
validation  shall  be  in  the  form  of  a  CSL  Certificate  of 
Validation . 
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Appendix  C 

Planning  Phase  Risk  Analysis 


A  planning  phase  risk  analysis  is  similar  to  a  "regular"  risk  analysis.   They  share 
the  same  goal  and  overall  strategy.   The  goal  is  to  identify  vulnerabilities  and 
offsetting  controls.   The  logical  outcome  of  any  risk  analysis  is  the  acquisition 
and/or  implementation  of  cost-effective  security  controls.   This  is  often  referred  to  as 
the  risk  reduction  phase.   (Another  product  of  the  risk  analysis  is  the  identification 
of  residual  risk  which  cannot  be  further  reduced  or  eliminated  in  an  economically 
feasible  manner  by  currently  available  means.) 

The  strategy  of  a  risk  analysis  is  to  examine  potential  losses  that  may  result  from 
weaknesses  in  system  security  and  the  damage  that  may  result  from  the  occurrence 
of  certain  threats.   In  order  to  do  this,  a  risk  analysis  contains  the  following 
components: 

Asset  identification  and  valuation 
Threat  analysis 
Vulnerability  assessment 
Impact  analysis 
Determination  of  risk 

Since  the  goal  of  a  risk  analysis  is  the  selection  of  cost-effective  safeguards,  a  risk 
analysis  is  actually  a  decision-support  tool.   By  identifying  those  areas  with  the 
greatest  potential  for  loss  or  harm,  the  risk  analysis  provides  a  basis  for  a  system 
manager  to  make  informed  choices  about  controls.   This  allows  the  manager  to 
allocate  precious  resources  based  on  need  and  expected  effectiveness. 

The  planning  phase  risk  analysis  is  performed  during  the  planning  stage  of  system 
acquisition  and  during  the  design  stage  of  a  system  life  cycle.   As  discussed  in 
section  III.B.l.b  and  section  III.B.2,  this  analysis  is  used  as  a  basis  for  deciding 
which  safeguards  are  mandatory  and  which  are  desirable.  The  analysis  should, 
therefore,  concentrate  on  items  that  are  related  to  system  acquisition  decisions.  In 
addition,  it  will  help  support  the  evaluation  plan's  ranking  of  the  desirable 
safeguards. 

As  the  term  "planning  phase"  implies,  further  risk  analysis  is  required  during  the  life 
of  a  system.   OMB  Circular  A- 130  requires  periodic  risk  analysis  for  general 
support  systems.   However,  depending  on  the  nature  of  the  system,  how  it  is  being 
developed  or  acquired,  and  other  factors,  there  are  many  places  during  the  systems 
life  when  a  form  of  risk  analysis  may  be  useful.  In  general,  risk  analysis  should  be 
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viewed  as  an  iterative  process  to  take  into  account  changes  in  the  system,  the 
system  environment,  and  knowledge  about  the  system.   The  nature  of  the  risk 
analysis  should  always  be  commensurate  with  the  placement  in  the  systems  life  and 
the  sensitivity  of  the  system. 

How  to  Perform  a  Planning  Phase  Risk  Analysis 

Although  a  planning  phase  risk  analysis  is  very  much  like  a  risk  analysis,  there  are 
differences.   A  planning  phase  risk  analysis  is  less  precise.  The  analysis  considers 
projected  costs,  assets,  threats  and  vulnerabilities,  not  current  ones.   The  impacts  of 
failures  are  based  on  a  projection  of  system  use.  The  emphasis  of  risk  analysis  is 
the  assessment  of  existing  assets  and  controls.  The  planning  phase  risk  analysis 
emphasizes  the  impacts  of  possible  security  problems  and  how  to  mitigate  them. 

The  planning  phase  risk  analysis  should  be  performed  in  keeping  with  federal  and 
agency  guidance.  The  agency  risk  analysis  office  or  computer  security  office  should 
be  consulted. 

The  planning  phase  risk  analysis  need  not  be  a  large  and  complex  document.  It 
should  focus  on  defining  and  documenting  system  security  requirements.  The 
purpose  of  a  risk  analysis  is  not  to  spend  a  lot  of  time  trying  to  quantify  or  describe 
assets  and  impacts  but  to  provide  a  basis  for  making  informed  decisions  about 
system  security.   Therefore,  the  level  of  detail  should  be  commensurate  with  the 
sensitivity  of  the  system  and  the  need  for  decision  support. 

Existing  agency  risk  analyses  can  be  used  as  a  starting  point.     Since  many 
information  processing  resources  are  bought  as  part  of  either  an  existing  facility, 
application,  or  system,  many  aspects  including  physical,  application,  user,  and  facility 
environment  may  already  be  known. 

A  planning  phase  risk  analysis  methodology  based  on  the  FIRMR,  Federal 
Information  Processing  Standard  Publication  (FIPS  PUB)  73  and  other  source 
material  is  presented  in  GAO  Report  Agencies  Overlook  Security  Controls  During 
Development  (GAO/IMTEC-88-11S)  and  reprinted  below.   Additional  material  on 
risk  analysis  is  available  from  the  sources  referenced  in  the  GAO  report  and  from: 

Special  Publication  500-174     Guide  for  Selecting  Automated  Risk  Analysis  Tools 
NISTIR  4325  U.S.  Department  of  Energy  Risk  Assessment 

Methodology 

NISTIR  4749  Sample  Statements  of  Work  for  Federal  Computer 

Security  Services. 
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GAO  Methodology 


This  is  a  risk  methodology,  based  on  a  system  development  life  cycle,  published  by 
the  GAO.   Agencies  can  use  other  methodologies  or  modify  this  one.   Nothing  in 
this  methodology  is  required.   The  methodology  does  not  provide  much  detail;  the 
references  cited  above  and  in  the  methodology  can  be  used  to  provide  additional 
guidance.   (Note:   FIRMR  citations  are  from  the  1988  version.) 

Initial  Risks 

1.  Identify  the  impact  of  major  failure  including: 

a.  an  analysis  of  expected  losses  calculated  in  dollars  or  other  significant 
indicators  (FIRMR,  Section  201-7.103-2)  such  as  (FIPS  73,  p.  27): 

1.  extent  of  inconvenience  or  hardship  to  individuals. 

2.  extent  of  lives  lost. 

3.  extent  of  disruption  to  the  national  economy  or  national  security. 

b.  an  analysis  of,  but  is  not  limited  to,  the  impact  of  the  following  risks 
(FIRMR,  Section  201-7.103-2): 

1.  physical  destruction  or  loss  of  data  and  program  files  (also  in 
FIPS  73,  p.  27;  FIPS  31,  p.  10). 

2.  theft  or  disclosure  of  information  (also  in  FIPS  73,  p.  7),  data 
confidentiality  issues  (FIPS  65,  p.  9),  improper  dissemination  and 
careless  disposal  (FIPS  41,  p.  12) 

3.  misuse  of  ADP  system,  that  is,  fraud,  vandalism,  etc.,  (see  also 
falsified  data,  FIPS  73,  p.  27;  theft  of  information  or  assets, 
FIPS  31,  p.  10). 

4.  delay  or  prevention  of  ADP  operation  (see  also  unavailable  data 
or  services,  FIPS  73,  p.  27). 

5.  lack  of  reliability  of  automated  data  processing  equipment  and 
utilities. 

6.  altered  or  inaccurate  data  (also  in  FIPS  73,  p.  25). 

c.  potential  impacts  are  assessed  for  every  application  that  will  maintain 
or  process  sensitive  or  mission-critical  information  (implied  in  FIPS  73, 
p.  27). 

2.  Estimate  the  frequency  of  major  failure  in  the  areas  of: 

a.  inaccurate  data, 

b.  falsified  data, 

c.  disclosed  data, 

d.  lost  data  or  programs,  and 

e.  unavailable  data  or  services  (FIPS  73,  p.  27). 
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3.  Estimate  the  cost  of  major  failures: 

a.  Calculate  an  annual  loss  expectancy  that  combines  the  estimates  of  the 
value  of  potential  loss  and  probability  of  loss  (FIPS  31,  p.  11).  See 
prior  risk  section  (2C.1.,2)  for  the  impact  and  frequency  of  failure 
estimates  that  the  agency  should  include  in  its  analysis. 

b.  Remedial  security  measures  are  identified  to  address  significant  threats 
(FIPS  31,  p.  13)  and  vulnerabilities  (FIPS  73,  p.  25),  including 
measures  such  as: 

1.  altering  the  environment  (FIPS  31,  p.  13), 

2.  erecting  barriers  (FIPS  31,  p.  13), 

3.  improving  procedures  (FIPS  31,  p.  13), 

4.  early  detection  (FIPS  31,  p.  13),  and 

5.  contingency  plans  (FIPS  31,  p.  13). 

c.  The  cost  of  remedial  measures  is  identified  including  an  identification 
of  the  least  cost  mix  of  security  measures  (FIPS  31,  p.  13). 
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GLOSSARY 


Appendix  D 


Acceptance  The  act  of  an  authorized  representative  of  the  government  by  which 
the  government,  for  itself  or  as  agent  of  another,  assumes  control  or  ownership  of 
existing  identified  supplies  tendered  or  approves  specific  services  rendered  as  partial 
or  complete  performance  of  the  contract.   It  is  the  final  determination  whether  or 
not  a  facility  or  system  meets  the  specified  technical  and  performance  standards. 

Access  control   Specifically  computer  systems  access  control.  Restrictions  on  the 
types  of  interactions  between  subjects  (i.e.,  persons)  and  objects  (i.e.,  files  or  data 
elements).   Access  can  be  divided  into  types  of  access  such  as  read,  write,  modify, 
or  execute.  (Access  control  also  includes  physical  access  control.) 

Acquisition   Acquiring  by  contract  with  appropriated  funds  supplies  or  services  by 
and  for  the  use  of  the  federal  government  through  purchase  or  lease,  whether  the 
supplies  or  services  are  already  in  existence,  or  must  be  created,  developed, 
demonstrated,  and  evaluated.   Acquisition  begins  at  the  point  when  agency  needs  are 
established  and  includes  the  description  of  requirements  to  satisfy  agency  needs, 
solicitation  and  selection  of  sources,  award  of  contract,  contract  financing,  contract 
performance,  contract  administration  and  those  technical  and  management  function 
directly  related  to  the  process  of  fulfilling  agency  needs  by  contract.   See  also 
procurement. 

Accreditation   A  critical  management  decision  made  by  an  agency  official  regarding 
the  adequacy  of  security  safeguards,  i.e.,  whether  the  safeguards  reduce  risk  to  an 
acceptable  level  for  the  intended  function.  It  must  be  based  on  reliable  technical 
information.   It  is  the  approval  to  operate  a  computer  system.   See  certification. 

ADP  Automatic  data  processing.   ADP  refers  to  the  resources  used  to  process 
automated  information,  including  telecommunications.  The  FIRMR  now  uses  the 
term  Federal  Information  Processing  (FIP)  resources. 

Administration  Specifically  contract  administration.  Government  management  of  a 
contract  to  ensure  that  the  government  receives  the  quality  of  products  and  services 
specified  in  the  contract  within  established  costs  and  schedules. 

Analysis  of  integrity,  availability,  and  confidentiality  requirements  An  analysis 
of  the  protection  requirements  of  a  system  based  on  the  system's  need  for  integrity, 
availability,  and/or  confidentiality. 
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Analysis  of  level  of  assurance  An  analysis  of  the  level  of  confidence  needed  that 
the  security  of  a  system  will  work  correctly  and  will  be  effective.  This  analysis 
forms  the  basis  for  the  procurement  evaluation  plan  and/or  acceptance  plan. 

Assurance  A  measure  of  confidence  that  the  security  features  and  architecture  of  a 
computer  system  meet  the  security  requirements. 

Authenticate  To  establish  the  validity  of  a  claimed  identity. 

BAFO  Best  and  Final  Offer.   An  opportunity  for  offerors  in  the  competitive  range 
to  submit  final  proposals. 

Bidder  Any  entity  that  responds  to  an  invitation  for  bids  with  a  bid.   See  offeror. 

Benchmark  A  test  of  the  capabilities  of  a  proposed  system  using  customized 
workloads 

Certification 

1)  Security  certification  A  technical  analysis  of  a  system  or  application  relative 
to  a  set  of  system  requirements  used  for  the  purpose  of  accreditation.  See 
accreditation. 

2)  Security  certification  A  technical  analysis  and  formal  declaration  by  an 
agency  official  that  an  application  or  system  meets  all  applicable  federal 
policies,  regulations,  and  standards,  and  that  safeguards  are  adequate  for  the 
application. 

3)  Procurement  certification  A  signed  statement  by  an  offeror. 

Closeout  Includes  all  final  contract  activities,  e.g.,  ensuring  completion  of  all 
requirements,  making  the  final  payment. 

Commercial  off-the-shelf  (COTS)  Software  and  hardware  that  already  exists.  It  is 
also  referred  to  as  off-the-shelf. 

Competition  in  Contracting  Act  of  1984  (CICA)  A  statute  that  made  several 
revisions  to  federal  contracting  including  requiring  that  specifications  be  developed  in 
an  "unrestricted  manner"  to  obtain  full  and  open  competition. 

Computer  Security  The  protection  of  automatic  data  processing  assets  from  harm. 
This  includes  the  protection  of  data,  hardware,  firmware,  and  software.  Harm  is 
defined  as  a  loss  of  integrity,  availability,  or  confidentiality. 

Computer  Security  Act  of  1987  A  statute  "to  provide  for  a  computer  standards 
program  with  the  (National  Institute  of  Standards  and  Technology),  to  provide  for 
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government-wide  computer  security,  and  to  provide  for  the  training  in  security 
matters  of  persons  who  are  involved  in  the  management,  operation,  and  use  of 
federal  computer  systems,  and  for  other  purposes." 

Confidential  Private,  nondisclosable.  (In  this  guideline  confidential  never  refers  to 
classified  material.) 

Contingency  planning  Plans  to  assure  that  users  can  continue  to  perform  essential 
functions  and  that  a  reasonable  continuity  of  data  processing  support  is  provided  at 
all  times.  These  plans  can  include  emergency  response,  backup  operation,  and  post- 
disaster  recovery. 

Contracting  Officer  (CO)  A  person  with  the  authority  to  enter  into,  administer, 
and/or  terminate  contracts  and  make  related  determination  and  findings. 

Contracting  Officer's  Technical  Representative  (COTR)  An  individual  to  whom 
the  Contracting  Officer  delegates  certain  contract  responsibilities,  usually  related  to 
technical  direction  and  acceptance  issues.   Also  called  Government  Technical 
Representative  (GTR)  or  the  Contracting  Officer's  Representative  (COR). 

DAC   See  discretionary  access  control. 

Delegation  of  Procurement  Authority  (DPA)  A  grant  of  authority  by  GSA  to 
acquire  FTP  resources  or  services.  See  section  II.B.2. 

Deliverable  A  product  or  service  that  is  prepared  for  and  delivered  to  the 
government  under  the  terms  of  a  contract. 

DES  Data  Encryption  Standard.  FIPS  PUB  46-1.   Specifies  an  algorithm  to  be 
implemented  for  cryptographic  protection  of  sensitive  data. 

Discretionary  access  control  A  means  of  restricting  access  to  objects  based  on  the 
identity  of  subjects  and/or  groups  to  which  they  belong.  The  controls  are 
discretionary  in  the  sense  that  a  subject  with  a  certain  access  permission  is  capable 
of  passing  that  permission  (perhaps  indirectly)  on  to  any  other  subject.   See  access 
control  and  mandatory  access  control. 

Directed  specification  A  specification  that  must  be  included  in  statements  of  work 
based  on  federal  law,  policy,  or  regulation. 

Domain  The  unique  context  in  which  a  program  is  operating. 
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Evaluation 

1)  Security  evaluation  The  examination  of  the  technical  and  nontechnical 
security  features  of  a  computer  system  and  other  safeguards  that  establishes  the 
extent  to  which  a  particular  design  and  implementation  meet  a  specified  set  of 
security  requirements. 

2)  Procurement  technical  evaluation  The  examination  of  proposals  in  order  to 
determine  technical  acceptability  and  merit.  This  is  part  of  the  source  selection 
process. 

3)  Product  security  evaluation  The  examination  of  the  security  features  of  a 
product  against  a  stated  set  of  requirements  or  criteria.  Product  evaluations  are 
often  performed  in  a  laboratory  setting. 

Federal  Acquisition  Regulation  (FAR)  The  regulation  that  codifies  uniform 
acquisition  policies  and  procedures  for  Executive  agencies. 

Federal  Information  Processing  (FIP)  FIP  refers  to  the  resources  and  services 
used  to  process  automated  information,  including  telecommunications. 

Federal  Information  Resources  Management  Regulation  (FIRMR)  The 

regulation  that  sets  forth  uniform  policies  and  procedures  pertaining  to  acquisition  of 
information  resources;  used  in  conjunction  with  the  FAR. 

Features  Specifically  technical  security  features.  The  security-relevant  functions, 
mechanisms,  and  characteristics  of  system  hardware,  firmware,  and  software. 
Technical  security  features  are  a  subset  of  system  security  safeguards. 

FIPS  PUB  Federal  Information  Processing  Standards  Publication 

Flowdown  The  extension  of  prime  contractor  requirements  to  subcontractors. 

Full  and  open  competition  The  consideration  of  all  responsible  sources  in  a 
procurement,  as  required  by  the  Competition  in  Contracting  Act. 

GSBCA   General  Services  Board  of  Contract  Appeals. 

GTR  Government  Technical  Representative.   See  Contracting  Officer's  Technical 
Representative. 

IFB   Invitation  for  Bid.   A  solicitation  document  used  when  contracting  by  sealed 
bids. 

ITSEC  Information  Technology  Security  Evaluation  Criteria.  The  harmonized 
security  criteria  of  France,  Germany,  the  Netherlands  and  the  United  Kingdom. 
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IY&V   Independent  Verification  and  Validation. 
Label 

1)  Security  label  A  piece  of  information  that  tells  a  system  how  to  handle  data. 
The  label  can  be  used  to  control  access,  specify  protective  measures,  or  indicate 
handling  restrictions  required  by  a  security  policy. 

2)  Access  control  label  A  piece  of  information  that  represents  the  security  level 
or  sensitivity  designation  of  data  in  an  object  or  the  access  authorization  of  a 
subject. 

Latent  defects  Defects  that  exist  at  the  time  of  acceptance  but  are  not  discoverable 
by  a  reasonable  inspection. 

Liquidated  damages  Compensation  to  the  government  for  damages  that  result  from 
the  contractor  failing  to  deliver  supplies  or  perform  services.  (See  FAR  12.2  and 
52.212-4). 

Live  test  demonstrations  (LTDs)  The  demonstration  of  capability  or  period  of 
time  during  which  a  government  user  requires  an  offeror  to  perform  certain  user- 
witnessed  activities.  These  can  include  one  or  more  benchmark  tests.  These  occur 
prior  to  contract  award. 

MAC  Message  authentication  code  or  mandatory  access  control. 

Mandatory  access  control  A  means  of  restricting  access  to  objects  based  on  the 
sensitivity  (as  represented  by  a  label)  of  the  information  contained  in  the  objects  and 
the  formal  authorization  of  subjects  to  access  information  of  such  sensitivity.   In  a 
mandatory  access  control  environment,  users  cannot  pass  their  access  rights  to  others 
without  express  concurrence  of  the  access  control  authority.   See  access  control  and 
discretionary  access  control. 

Mandatory  requirements  Those  contractual  conditions  and  technical  specifications 
that  are  established  by  the  government  as  being  essential  to  meeting  required  needs. 

Mechanism   Specifically  security  mechanism.   See  safeguard. 

Multi-label   Having  information  with  different  sensitivities  on  one  system.   A  multi- 
label  secure  system  permits  simultaneous  access  by  users  not  authorized  by  the 
mandatory  access  authority  to  access  all  of  the  data  and  prevents  unauthorized 
access.  This  term  is  normally  used  to  describe  systems  with  nonhierarchical 
information  sensitivities  and  where  the  system  is  relied  upon  to  enforce  a  mandatory 
policy.   See  label  and  multilevel. 
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Multilevel   Having  information  with  different  sensitivities  on  one  system.  A 
multilevel  secure  system  permits  simultaneous  access  by  users  not  authorized  by  the 
mandatory  access  authority  to  access  all  of  the  data  and  prevents  unauthorized 
access.   This  term  is  normally  used  to  describe  systems  with  hierarchical  information 
sensitivities  and  where  the  system  is  relied  upon  to  enforce  a  mandatory  policy.  See 
multi-label. 

Needs  determination  An  assessment,  performed  as  part  of  initial  system  planning, 
which  looks  at  the  needs  of  an  agency  that  might  be  met  through  automation. 

Object   A  passive  entity  that  contains  or  receives  information.   Access  to  an  object 
implies  access  to  the  information  it  contains.  Examples  of  objects  are:  records, 
blocks,  files,  programs,  video  displays,  printers,  network  nodes,  etc. 

Object  reuse  The  removal  of  residual  data  from  a  system  resource  prior  to 
reassignment  and  reuse. 

Off-the-shelf  Software  and  hardware  that  already  exists.  It  is  also  referred  to  as 
commercial  off-the-shelf  (COTS). 

Offeror   Any  entity  that  responds  to  an  RFP  with  a  proposal.   See  bidder. 
Orange  Book   See  TCSEC. 

Preaward  survey   An  evaluation  by  a  surveying  activity  of  a  prospective 
contractor's  capability  to  perform  a  proposed  contract. 

Presolicitation  The  period  preceding  release  of  a  solicitation  that  includes 
preparation  of  documentation  required  by  federal  regulations. 

Procedure  Specifically  security  procedure.   A  type  of  safeguard  based  on  human 
actions  (as  opposed  to  technical  features).  These  can  be  referred  to  as 
administrative  safeguards. 

Procurement  Includes  all  stages  of  the  process  of  acquiring  property  or  services, 
beginning  with  the  process  for  determining  need  for  the  property  or  services  and 
ending  with  contract  completion  and  closeout. 

Procurement  initiator  The  key  person  who  represents  the  program  office  in 
formulating  information  resources  requirements  and  managing  presolicitation 
activities.   Also  called  program  manager,  sponsor.  This  person  often  becomes  the 
contracting  officer's  technical  representative  (COTR). 
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Program  manager  See  procurement  initiator. 

Protest  A  written  objection  by  an  interested  party  to  a  solicitation  for  a  proposed 
contract  for  the  acquisition  of  supplies  or  services  or  a  written  objection  by  an 
interested  party  to  a  proposed  award  or  the  award  of  such  a  contract. 

RFC   Request  for  Comment.   An  announcement  requesting  industry  comment  on  a 
proposed  system  or  other  acquisition. 

RFI  Request  for  Information.   An  announcement  requesting  information  from 
industry  in  regard  to  a  planned  acquisition  and,  in  some  cases,  requesting  corporate 
capability  information. 

RFP  Request  for  Proposals.  A  solicitation  document  used  in  negotiated 
acquisitions  to  communicate  government  requirements  and  to  solicit  proposals. 

RFQ  Request  for  Quotation.  A  solicitation  document  used  in  negotiated 
acquisitions  to  communicate  government  requirements  and  to  solicit  quotations. 

Requirements  analysis  A  part  of  the  acquisition  cycle  in  which  the  requirements 
for  a  system  are  developed. 

Responsible  prospective  contractor  To  be  responsible,  a  prospective  contractor 
must  meet  the  requirements  of  FAR  9.104-1  which  include  the  ability  to  be  able 
perform  the  contract  based  on  the  financial,  technical,  organizational,  ethical,  and 
legal  position  of  the  contractor. 

Responsive  prospective  contractor  To  be  responsive,  a  prospective  contractor  must 
comply  in  all  material  respects  with  the  solicitation. 

Restrictive  specification  A  detailed  and  precise  description  of  an  item(s)  being 
acquired  that  needlessly  limits  competition,  e.g.,  "brand  name"  without  the  words  "or 
equal." 

Risk  analysis  The  process  of  examining  assets,  threats,  and  vulnerabilities  in  order 
to  determine  cost-effective  security  controls. 

Safeguard   Any  action,  device,  feature,  mechanism,  procedure,  technique,  or  other 
measure  that  reduces  the  vulnerability  of  or  threat  to  a  system.  Also  called  controls 
or  countermeasures. 
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Sensitive  information  Any  information  which  the  loss,  misuse,  modification  of,  or 
unauthorized  access  to,  could  affect  the  national  interest  or  the  conduct  of  federal 
programs,  or  the  privacy  to  which  individuals  are  entitled  under  Section  552a  of 
Title  5,  U.S.  Code,  but  that  has  not  been  specifically  authorized  under  criteria 
established  by  an  Executive  order  or  an  act  of  Congress  to  be  kept  classified  in  the 
interest  of  national  defense  or  foreign  policy. 

Sensitivity  assessment  An  initial  assessment  of  the  general  sensitivity  of  an  agency 
function. 

Single-label  A  subset  of  a  multi-label  system  in  which  only  one  type  of  labeled 
information  is  processed  at  a  time.   See  label  and  multi-label. 

Solicitation   An  official  government  request  for  bids/proposals  often  publicized  in 
the  Commerce  Business  Daily. 

Source  selection  The  process  of  evaluating  proposals  and  determining  which  offeror 
will  be  selected  for  contract  award. 

SEB   Source  Evaluation  Board.    A  board  comprised  of  technical,  contract, 
information  resources  management,  and  other  representatives  whose  primary  function 
is  to  evaluate  proposals  received  in  response  to  an  RFP. 

Specification  A  description  of  the  technical  requirements  for  a  material,  product,  or 
service.   Specifications  should  state  only  the  government's  actual  minimum  needs 
and  be  designed  to  promote  full  and  open  competition,  with  due  regard  for  the 
nature  of  the  services  to  be  acquired. 

Sponsor  See  procurement  initiator. 

Statement  of  work  (SOW)  A  statement  of  the  technical  specification  in  the  RFP 
that  describes  the  work  or  system  required  by  the  government. 

Subject  An  active  entity,  generally  a  person,  process,  or  device  that  causes  actions 
such  as  the  flow  of  information. 

TCSEC  Trusted  Computer  System  Evaluation  Criteria.  DoD  5200.28-STD.  The 
Department  of  Defense  security  evaluation  criteria.  Also  called  the  Orange  Book. 

Threat  Any  circumstance  or  event  with  the  potential  to  cause  harm  to  a  system  in 
the  form  of  destruction,  disclosure,  modification  of  data,  and/or  denial  of  service. 
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Trusted  computing  base  (TCB)  Specifically  DoD  5200.28.  The  totality  of 
protection  mechanisms  within  a  computer  system  —  including  hardware,  firmware, 
and  software  —  that  are  responsible  for  enforcing  a  security  policy. 

Vetting   Specifically  personnel  vetting.   The  process  of  investigating  personnel  with 
the  intent  to  approve  or  disapprove  access  to  government  resources.  The 
investigations  can  range  from  minimal  checks  to  full  background  investigations. 
Also  called  personnel  screening. 

Vulnerability  A  weakness  in  system  security  procedures,  system  design, 
implementation,  internal  controls,  physical  environment,  etc. 

Warner  Amendment   10  USCA  2315.  Excludes  certain  systems  from  the 
requirements  of  Section  111  of  the  Federal  Property  and  Administrative  Services  Act 
of  1949  (40  USC  795),  including  automatic  data  processing  equipment  or  services  if 
the  function,  operation,  or  use  of  the  equipment  of  services  involves  intelligence 
activities,  involves  cryptographic  activities  related  to  national  security,  involves  the 
command  and  control  of  military  forces,  equipment  that  is  an  integral  part  of  a 
weapon  or  weapons  system,  or  is  critical  to  the  direct  fulfillment  of  military  or 
intelligence  missions  except  for  equipment  or  services  to  be  used  for  routine 
administrative  and  business  application  (including  payroll,  finance,  logistics,  and 
personnel  management  applications). 
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